Yes Phil
> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net" > <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> > An: tors...@lodderstedt.net,John Bradley <ve7...@ve7jtb.com> > Cc: 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] On Behalf Of > tors...@lodderstedt.net > Sent: Saturday, February 13, 2016 6:37 AM > To: John Bradley <ve7...@ve7jtb.com> > Cc: 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> > An: tors...@lodderstedt.net > Cc: 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 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> > Gesendet: Friday, February 12, 2016 05:45 PM > An: 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>: > > > > +1 to adopt this draft. > > > >> On Feb 12, 2016, at 3:07 AM, Mike Jones <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] On Behalf Of Hannes Tschofenig > >> Sent: Thursday, February 4, 2016 11:23 AM > >> To: 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 > >> > >> 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 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 > >> > >> 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 > >> > >> 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 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 > >> 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 > >> > >> 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 > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > 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 > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
