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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
