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