We’re a standard body working group. We don’t do “efficient”. ;) — Justin
> On Feb 13, 2016, at 3:19 PM, Mike Jones <michael.jo...@microsoft.com> wrote: > > It's an acceptable fallback option if the working group decides it doesn't > want to register the values that are already in production use at the time we > establish the registry. But add William points out, Google is already using > some of these values. Microsoft is using some of them. The OpenID MODRNA > specs are using some of them. So it seems more efficient to register them at > the same time. > > That would be my preference. > > -- Mike > From: Justin Richer <mailto:jric...@mit.edu> > Sent: 2/13/2016 11:11 AM > To: Phil Hunt <mailto:phil.h...@oracle.com> > Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for > Adoption Finalized > > Can we just do that, then? Seems to be the easiest way to address various > needs and concerns. > > — Justin > >> On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) <phil.h...@oracle.com >> <mailto:phil.h...@oracle.com>> wrote: >> >> Yes >> >> Phil >> >> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net >> <mailto:tors...@lodderstedt.net>" <tors...@lodderstedt.net >> <mailto:tors...@lodderstedt.net>> wrote: >> >>> So basically, the RFC could also just establish the new registry and oidf >>> could feel in the values? >>> >>> (just trying to understand) >>> >>> >>> >>> -------- Originalnachricht -------- >>> Betreff: RE: [OAUTH-WG] Authentication Method Reference Values: Call for >>> Adoption Finalized >>> Von: Mike Jones <michael.jo...@microsoft.com >>> <mailto:michael.jo...@microsoft.com>> >>> An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>,John Bradley >>> <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> >>> Cc: oauth@ietf.org <mailto:oauth@ietf.org> >>> >>> The context that most people on this thread probably don’t have is that an >>> IANA registry can only be established by an RFC. Non-RFC specifications, >>> such as OpenID specifications, can *register* values in a registry, but >>> they cannot *establish* a registry. The OpenID Foundation inquired about >>> this with the IETF before OpenID Connect was finalized and learned that its >>> specifications could not establish IANA registries. Otherwise, they would >>> have. >>> >>> >>> Instead, RFCs need to be created to establish registries – even for values >>> first defined in non-RFC specifications. This specification is one example >>> of doing this. >>> >>> >>> -- Mike >>> >>> <> >>> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] >>> On Behalf Of tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >>> Sent: Saturday, February 13, 2016 6:37 AM >>> To: John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> >>> Cc: oauth@ietf.org <mailto:oauth@ietf.org> >>> Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >>> Adoption Finalized >>> >>> >>> We clearly have this problem between oauth and oidc. Just take a look at >>> the discovery thread. >>> >>> According to you argument I see two options: >>> (1) amr stays an oidc claim, is used in oidc only and the oauth wg just >>> publishes the registry entries. In this case, the spec should clearly >>> explain this. >>> (2) amr is of any use in oauth (although it has been invented in oidc) - >>> than define it and motivate it's use in oauth in this spec. >>> >>> Right now, I think it creates the impression oauth is for authentication. >>> >>> >>> >>> -------- Originalnachricht -------- >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >>> Adoption Finalized >>> Von: John Bradley <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>> >>> An: tors...@lodderstedt.net <mailto:tors...@lodderstedt.net> >>> Cc: roland.hedb...@umu.se,oauth@ietf.org >>> <mailto:roland.hedb...@umu.se,oauth@ietf.org> >>> >>> This is not a issue between oauth and OIDC. >>> >>> >>> This has to do with the registry for JWT being in OAuth. Many protocols >>> that use JWT are going to want to register claims. >>> >>> We can’t ask them to all move the parts of there specs that use JWT to >>> OAuth. >>> >>> >>> Perhaps JWT should have been part of JOSE, but that is water under the >>> bridge. >>> >>> >>> The OAuth WG is responsible for JWT and it’s registry, and we will need to >>> deal with registering claims. >>> >>> >>> I guess that we can tell people that they need to publish the specs >>> defining the claims someplace else, and just do the registry part. >>> >>> However doing that will probably not improve interoperability and >>> understanding. >>> >>> >>> This document defines the claim for JWT in general. We still have almost >>> no documentation in the WG about what a JWT access token would contain >>> other than the POP work. >>> >>> >>> John B. >>> >>> On Feb 13, 2016, at 9:18 AM, tors...@lodderstedt.net >>> <mailto:tors...@lodderstedt.net> wrote: >>> >>> >>> I basically support adoption of this document. Asserting authentication >>> methods in access tokens (in this case in JWTS format) is reasonable. We >>> use it to pass information about the authentication performed prior issuing >>> an access token to the _resource_ server. >>> >>> What worries me is the back and forth between oauth and oidc. The amr claim >>> is defined in oidc (which sits on top of oauth) but the oauth wg specifies >>> the registry? Moreover, the current text does not give a rationale for >>> using amr in context of oauth. >>> >>> As a WG we need to find a clear delineation between both protocols, >>> otherwise noone will really understand the difference and when to use what. >>> We create confusion! >>> >>> For this particular draft this means to either move amr to oauth or the >>> registry to oidc. >>> >>> best regards, >>> Torsten. >>> >>> >>> >>> -------- Ursprüngliche Nachricht -------- >>> Von: Roland Hedberg <roland.hedb...@umu.se <mailto:roland.hedb...@umu.se>> >>> Gesendet: Friday, February 12, 2016 05:45 PM >>> An: oauth@ietf.org <mailto:oauth@ietf.org> >>> Betreff: Re: [OAUTH-WG] Authentication Method Reference Values: Call for >>> Adoption Finalized >>> >>> +1 >>> >>> > 12 feb 2016 kl. 16:58 skrev John Bradley <ve7...@ve7jtb.com >>> > <mailto:ve7...@ve7jtb.com>>: >>> > >>> > +1 to adopt this draft. >>> > >>> >> On Feb 12, 2016, at 3:07 AM, Mike Jones <michael.jo...@microsoft.com >>> >> <mailto:michael.jo...@microsoft.com>> wrote: >>> >> >>> >> Draft -05 incorporates the feedback described below - deleting the >>> >> request parameter, noting that this spec isn't an encouragement to use >>> >> OAuth 2.0 for authentication without employing appropriate extensions, >>> >> and no longer requiring a specification for IANA registration. I >>> >> believe that it’s now ready for working group adoption. >>> >> >>> >> -- Mike >>> >> >>> >> -----Original Message----- >>> >> From: OAuth [mailto:oauth-boun...@ietf.org >>> >> <mailto:oauth-boun...@ietf.org>] On Behalf Of Hannes Tschofenig >>> >> Sent: Thursday, February 4, 2016 11:23 AM >>> >> To: oauth@ietf.org <mailto:oauth@ietf.org> >>> >> Subject: [OAUTH-WG] Authentication Method Reference Values: Call for >>> >> Adoption Finalized >>> >> >>> >> Hi all, >>> >> >>> >> On January 19th I posted a call for adoption of the Authentication >>> >> Method Reference Values specification, see >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15402.html> >>> >> >>> >> What surprised us is that this work is conceptually very simple: we >>> >> define new claims and create a registry with new values. Not a big deal >>> >> but that's not what the feedback from the Yokohama IETF meeting and the >>> >> subsequent call for adoption on the list shows. The feedback lead to >>> >> mixed feelings and it is a bit difficult for Derek and myself to judge >>> >> consensus. >>> >> >>> >> Let me tell you what we see from the comments on the list. >>> >> >>> >> In his review at >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15423.html> James >>> >> Manger asks for significant changes. Among other things, he wants to >>> >> remove one of the claims. He provides a detailed review and actionable >>> >> items. >>> >> >>> >> William Denniss believes the document is ready for adoption but agrees >>> >> with some of the comments from James. Here is his review: >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15426.html> >>> >> >>> >> Justin is certainly the reviewer with the strongest opinion. Here is one >>> >> of his posts: >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15457.html> >>> >> >>> >> Among all concerns Justin expressed the following one is actually >>> >> actionable IMHO: Justin is worried that reporting how a person >>> >> authenticated to an authorization endpoint and encouraging people to use >>> >> OAuth for authentication is a fine line. He believes that this document >>> >> leads readers to believe the latter. >>> >> >>> >> John agrees with Justin in >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15448.html> that >>> >> we need to make sure that people are not mislead about the intention of >>> >> the document. John also provides additional comments in this post to the >>> >> list: http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15441.html> >>> >> Most of them require more than just editing work. For example, methods >>> >> listed are really not useful, >>> >> >>> >> Phil agrees with the document adoption but has some remarks about the >>> >> registry although he does not propose specific text. His review is here: >>> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html >>> >> <http://www.ietf.org/mail-archive/web/oauth/current/msg15462.html> >>> >> >>> >> With my co-chair hat on: I just wanted to clarify that registering >>> >> claims (and values within those claims) is within the scope of the OAuth >>> >> working group. We standardized the JWT in this group and we are also >>> >> chartered to standardize claims, as we are currently doing with various >>> >> drafts. Not standardizing JWT in the IETF would have lead to reduced >>> >> interoperability and less security. I have no doubts that was a wrong >>> >> decision. >>> >> >>> >> In its current form, there is not enough support to have this document >>> >> as a WG item. >>> >> >>> >> We believe that the document authors should address some of the easier >>> >> comments and submit a new version. This would allow us to reach out to >>> >> those who had expressed concerns about the scope of the document to >>> >> re-evaluate their decision. A new draft version should at least address >>> >> the following issues: >>> >> >>> >> * Clarify that this document is not an encouragement for using OAuth as >>> >> an authentication protocol. I believe that this would address some of >>> >> the concerns raised by Justin and John. >>> >> >>> >> * Change the registry policy, which would address one of the comments >>> >> from James, William, and Phil. >>> >> >>> >> Various other items require discussion since they are more difficult to >>> >> address. For example, John noted that he does not like the use of >>> >> request parameters. Unfortunately, no alternative is offered. I urge >>> >> John to provide an alternative proposal, if there is one. Also, the >>> >> remark that the values are meaningless could be countered with an >>> >> alternative proposal. James wanted to remove the "amr_values" parameter. >>> >> Is this what others want as well? >>> >> >>> >> After these items have been addressed we believe that more folks in the >>> >> group will support the document. >>> >> >>> >> Ciao >>> >> Hannes & Derek >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> >> <https://www.ietf.org/mailman/listinfo/oauth> >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org <mailto:OAuth@ietf.org> >>> > https://www.ietf.org/mailman/listinfo/oauth >>> > <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> — Roland >>> >>> ”Everybody should be quiet near a little stream and listen." >>> From ’Open House for Butterflies’ by Ruth Krauss >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
