Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

[Torsten Lodderstedt <[e-mail]>]

Hi Denniss,

out of curiosity: Does Google use amr values?

best regards,
Torsten.

Am 14.02.2016 um 02:40 schrieb William Denniss:
>
>
> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones 
> <[e-mail] <mailto:[e-mail]>> 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.
>
>
> +1, it is also my preference to register the current values.
>
> I don't see any harm in the spec that establishes the registry also 
> seeding it with all known values in use at the time of drafting, 
> regardless of the group that originally specified them. Makes the 
> original spec more useful, and avoids the need to submit each value 
> for consideration separately – they can be all be reviewed at the same 
> time.
>
>
>     From: Justin Richer <mailto:[e-mail]>
>     Sent: ‎2/‎13/‎2016 11:11 AM
>     To: Phil Hunt <mailto:[e-mail]>
>
>     Cc: <[e-mail]> <mailto:[e-mail]>
>     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)
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     Yes
>>
>>     Phil
>>
>>     On Feb 13, 2016, at 07:59, "[e-mail]
>>     <mailto:[e-mail]>" <[e-mail]
>>     <mailto:[e-mail]>> 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 <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     An: [e-mail]
>>>     <mailto:[e-mail]>,John Bradley <[e-mail]
>>>     <mailto:[e-mail]>>
>>>     Cc: [e-mail] <mailto:[e-mail]>
>>>
>>>     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:[e-mail]] *On Behalf Of
>>>     *[e-mail] <mailto:[e-mail]>
>>>     *Sent:* Saturday, February 13, 2016 6:37 AM
>>>     *To:* John Bradley <[e-mail] <mailto:[e-mail]>>
>>>     *Cc:* [e-mail] <mailto:[e-mail]>
>>>     *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 <[e-mail] <mailto:[e-mail]>>
>>>     An: [e-mail] <mailto:[e-mail]>
>>>     Cc: [e-mail],[e-mail]
>>>     <mailto:[e-mail],[e-mail]>
>>>
>>>     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, [e-mail]
>>>         <mailto:[e-mail]> 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 <[e-mail]
>>>         <mailto:[e-mail]>>
>>>         Gesendet: Friday, February 12, 2016 05:45 PM
>>>         An: [e-mail] <mailto:[e-mail]>
>>>         Betreff: Re: [OAUTH-WG] Authentication Method Reference
>>>         Values: Call for Adoption Finalized
>>>
>>>         +1
>>>
>>>         > 12 feb 2016 kl. 16:58 skrev John Bradley
>>>         <[e-mail] <mailto:[e-mail]>>:
>>>         >
>>>         > +1 to adopt this draft.
>>>         >
>>>         >> On Feb 12, 2016, at 3:07 AM, Mike Jones
>>>         <[e-mail]
>>>         <mailto:[e-mail]>> 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:[e-mail]] On Behalf Of
>>>         Hannes Tschofenig
>>>         >> Sent: Thursday, February 4, 2016 11:23 AM
>>>         >> To: [e-mail] <mailto:[e-mail]>
>>>         >> 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
>>>         >> [e-mail] <mailto:[e-mail]>
>>>         >> https://www.ietf.org/mailman/listinfo/oauth
>>>         >
>>>         > _______________________________________________
>>>         > OAuth mailing list
>>>         > [e-mail] <mailto:[e-mail]>
>>>         > 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
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         [e-mail] <mailto:[e-mail]>
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>     _______________________________________________
>>     OAuth mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth