Maybe I'm getting confused over the terminology. Connect speaks of a client talking to a CheckID endpoint or UserInfo endpoint. Is the RS acting as the client in this case?
I'm actually looking at your famous PDF diagrams Justin, and it looks like the client is in all cases the same client. E.g. the client that asks for the access token is the same client performs the UserInfo request or CheckID request. In my mind, I want the client to get the access-token and present it to the RS, and then I want the RS to perform the UserInfo request or CheckID request. So if you're telling me that the RS is acting as the client, and the RS can perform the UserInfo request or CheckID request, then I get it. But it wasn't obvious from the spec. Tx! adam -----Original Message----- From: Richer, Justin P. [mailto:jric...@mitre.org] Sent: Friday, June 01, 2012 10:00 AM To: Manger, James H Cc: Lewis Adam-CAL022; oauth@ietf.org Subject: Re: [OAUTH-WG] Inter-domain AS/RS communication (revisited) More specifically, OpenID Connect with the addition of reusing the access_token provided by the AS to get at other API services. This capability is explicitly encouraged in Connect since it directly re-uses the OAuth2 infrastructure and tokens to do the identity protocol. -- Justin On Jun 1, 2012, at 10:33 AM, Manger, James H wrote: > Adam, > > You are describing OpenID Connect. > > -- > James Manger > > ----- Reply message ----- > From: "Lewis Adam-CAL022" <adam.le...@motorolasolutions.com> > Date: Sat, Jun 2, 2012 12:00 am > Subject: [OAUTH-WG] Inter-domain AS/RS communication (revisited) > To: "oauth@ietf.org" <oauth@ietf.org> > > Hi all, > > I've asked about the lack of standardization of the AS-RS interface in the > past, but I have a new twist on my question. What is the viability of > performing user "authentication" using OAuth with an RS in domain-1, and a > whole bunch of AS's in different domains (assuming that the RS and AS is of > the same implementation)? > > RS (domain-1) > > AS-1 AS-2 AS-3 AS-4 AS-5 AS-6 AS-n > > Let me explain a bit further. I have a RS in domain-1 which exposes an API, > which is accessed by a native client, with users from (for example) 12 > different domains. (Note: both the RS and native clients are of the same > vendor implementation). Each of the 12 user domains has an AS, of the same > implementation as the RS in domain-1. I'm thinking that native client users > from domain X should be able to authenticate to the AS in their home domain > using some primary authentication means, obtain an unstructured access-token, > and present that access-token to the RS in domain-1. Because they are all of > the same implementation, the RS in domain-1 should be able to make a RESTful > API call to the AS in domain X to obtain a JSON structure, containing among > other things, the user's name, and possibly other attributes. Hence > secondary authentication has been realized. > > This seems to work, but is this within the spirit of OAuth, or have I gone > off into LaLa land? We have looked at using the SAML bearer assertion > profile for OAuth, but we do a lot over wireless links, many of which are > bandwidth anemic, and the overhead of obtaining the SAML assertion and > sending it are making me a bit squeamish. OAuth is attractive because of its > light weight-ness. Is the usage I'm proposing of OAuth (above) something > that would be within the overall spirit of the OAuth framework? > > Tx! > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
