The argument about confusing draft-hunt-oauth-v2-user-a4c-03 with the OpenID Connect work is indeed something to be careful about. Maybe this could be addressed by more precisely capturing the differences in a section of the document.
Ciao Hannes On 06/05/2014 10:11 PM, John Bradley wrote: > Looking at the latest draft > http://tools.ietf.org/html/draft-hunt-oauth-v2-user-a4c-03 it is better. > > As far as I can see he deltas from Connect Basic profile are: > 1 A new response_type "code_id_token" (I think the similarity to the "code > id_token" response_type may cause some confusion but that can be sorted out.) > 2 a new request parameter "min_alv" (I think min_alv="2" is isomorphic to > acr_values="4 3 2" so having 2 ways to make the same request may not be > ideal, but that can be debated.) > > In Connect we probably would have added a way to get id_token only from the > token endpoint but RFC6849 requires a access token be issued for a grant_type > of authorization_code. > > I think to be consistent with RFC6849 a new grant type needs to be defined. > > In previous discussions returning a access token with no scopes was > considered easier than trying to explain a OAuth flow with no access token. > This needs discussion. > > Other than that Mike has done a good job of reconciling a4c with Connect > Basic profile. > > This spec on it's own would not allow you to do any sort of scalable SSO, as > the trust model is unspecified other than trusting the JWT based on the TLS > cert of the token endpoint. > I think there needs to be some validation of issuer if there is more than one > the client is dealing with. > > It is Shorter than Connect basic because it leaves out interoperating with > multiple IdP and user attributes. > > I don't hate it, but don't know that it adds much, other than possible > confusion and future extensions that are incompatible with Connect. > > It is however better than it was. > > John B. > > On Jun 5, 2014, at 1:46 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > >> Hannes, the Access Token and ID Token do quite different things and have >> different structures and properties. The Access Token is an opaque value >> that grants access to resources. An ID Token is a non-opaque JWT security >> token that makes claims about the authentication that occurred. You can >> have one without the other or you can have both, depending upon the use >> case. Thus, trying to move information between them would be problematic in >> several regards. >> >> Also, trying to overload the Access Token to convey authentication >> information has been demonstrated in practice to be fraught with peril, and >> has resulted in some of the most prominent security breaches related to the >> misuse of OAuth. >> >> -- Mike >> >> -----Original Message----- >> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt >> Sent: Thursday, June 05, 2014 8:54 AM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Question regarding draft-hunt-oauth-v2-user-a4c >> >> You are correct. Just adding to access token would make a lot of devs happy >> and that certainly should be discussed. >> >> Two requirements issues: >> >> 1. A key use case is passing auth ctx only. An access token means asking for >> consent to access something. This causes many sites to loose new users. >> Authen only can be implicit consent. >> >> 2. Compatibility with OpenId ID Token and flows. >> >> 3. There is a need to support re-auth and MFA/LOA negotiation. Eg web site >> would like to obtain a higher level of assurance for a higher risk action. >> >> The non-tech requirement is the soln must be received by client and service >> provider developers as easy to implement in addition to 6749 or even OAuth >> 1.1a. I mention it because devs feel this should be trivial. Your >> suggestion of adding to access token certainly fits this. >> >> Phil >> >>> On Jun 5, 2014, at 0:44, Hannes Tschofenig <hannes.tschofe...@gmx.net> >>> wrote: >>> >>> Hi Phil, >>> >>> thanks for producing this document write-up. I have a somewhat basic >>> question regarding the document. >>> >>> The id token contains the following mandatory information: >>> - sis: issuer >>> - sub: subject >>> - aud: audience >>> - iat: issued at >>> - exp: expiry >>> - auth_time: time when the end user was authenticated >>> >>> An access token (when encoded as a JWT) may contain all these fields >>> except the auth_time (since auth_time is not defined in the JWT spec). >>> >>> Given that your proposal actually does not define the authentication >>> protocol to be used between the resource owner/end user and the >>> authorisation server I am wondering whether it would be possible to >>> just add the auth_time parameter (and maybe some of the optional >>> parameters) to the access token. Then, you can skip the id token. >>> >>> How do I come up with that question? In Kerberos, for example, the >>> above-listed information is carried within a single container (within >>> the ticket) and so I am curious to hear why we have to send the >>> information twice in OAuth (once in the access token, when the info is >>> passed per value, and again via the id token). >>> >>> Maybe I missing something important here. >>> >>> Ciao >>> Hannes >>> >>> >> >> _______________________________________________ >> 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
