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