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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Jan 2016 12:48:06 +0100

Hi all,

this is the call for adoption of Authentication Method Reference Values, see
https://tools.ietf.org/html/draft-jones-oauth-amr-values-03

Please let us know by Feb 2nd whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Note: The feedback during the Yokohama meeting was inconclusive, namely
9 for / zero against / 6 persons need more information.

You feedback will therefore be important to find out whether we should
do this work in the OAuth working group.

Ciao
Hannes & Derek

---

From: "Manger, James" <[email-masked]>
Date: Wed, 20 Jan 2016 15:37:33 +1100

Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting point for work.
I would like to see significant changes though:

* The "amr_values" parameter should be dropped; it just encourages brittle designs as section 4 "relationship to acr" and section 6 "security considerations" already warn about. There is no need to enable that brittleness. If someone really wants this functionality they could put an amr value in the "acr_values" field as a hack.

* The model for amr_values is wrong as well. For example, "amr":["pwd","otp"] could be a common response that you want, but you cannot ask for that with amr_values since amr_values="pwd otp" actually means just "pwd", or just "otp" is okay (and just "pwd" is your preference).

* Registering values on a "Specification Required" basis is over-the-top. This doc registers 8 amr values with just a few words as each value's "specification" (eg "eye": retina scan biometric). Each of the other 7 amr values are "specified" in a few lines with a reference (or two). A "First Come First Served" basis is probably sufficient, with the "specification" just the description in the registry (that can include references).

--
James Manger

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, 19 January 2016 10:48 PM
To: [email-masked]
Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

Hi all,

Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group.

You feedback will therefore be important to find out whether we should do this work in the OAuth working group.

Ciao
Hannes & Derek

---

From: William Denniss <[email-masked]>
Date: Wed, 20 Jan 2016 14:38:59 +0800

> Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting

+1 for adoption.

> * The "amr_values" parameter should be dropped; it just encourages brittle
> designs as section 4 "relationship to acr" and section 6 "security
> considerations" already warn about. There is no need to enable that
> brittleness. If someone really wants this functionality they could put an
> amr value in the "acr_values" field as a hack.
>

I agree that it seems to encourage brittle designs. Why would the OP want
to use "otp" when it has U2F on file for the same user, for example? But
come to think of it, is any use of "amr" non-brittle?  I guess the broader
ones like "user", "rba", "mca" and "mfa" are a little more future-proof.

I'm very keen to hear some concrete use-cases for this parameter.

* The model for amr_values is wrong as well. For example,
> "amr":["pwd","otp"] could be a common response that you want, but you
> cannot ask for that with amr_values since amr_values="pwd otp" actually
> means just "pwd", or just "otp" is okay (and just "pwd" is your preference).
>
> * Registering values on a "Specification Required" basis is over-the-top.
> This doc registers 8 amr values with just a few words as each value's
> "specification" (eg "eye": retina scan biometric). Each of the other 7 amr
> values are "specified" in a few lines with a reference (or two). A "First
> Come First Served" basis is probably sufficient, with the "specification"
> just the description in the registry (that can include references).
>

I agree, "Specification Required" does seem like a high bar.

> Please let us know by Feb 2nd whether you accept / object to the adoption
> of this document as a starting point for work in the OAuth working group.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jan 2016 16:59:05 -0300

I have always been on record as being against having this as a request parameter, and managed to keep it out of connect.
So will be looking to do the same with this.

In a response as a list of that methods were used it is mostly harmless.  People think they need it until they discover that it is not really useful in most circumstances.

The methods listed are really not useful,  but might be OK as general categories of response.

Fido U2F and UAF fall into what I would call Phishing resistant credentials,  is that something a RP should care about or is that reflected in the LoA.

In the MODRNA profile of OpenID Connect I added some other ones to indicate if the key is hardware or software etc.

This is probably a OK place to start from so I am OK with adopting it, but will push for change:)

John B.

> On Jan 20, 2016, at 3:38 AM, William Denniss <[email-masked]> wrote:
> 
> On Wed, Jan 20, 2016 at 12:37 PM, Manger, James <[email-masked] <mailto:[email-masked]>> wrote:
> I agree that it seems to encourage brittle designs. Why would the OP want to use "otp" when it has U2F on file for the same user, for example? But come to think of it, is any use of "amr" non-brittle?  I guess the broader ones like "user", "rba", "mca" and "mfa" are a little more future-proof.
> 
> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
> To: [email-masked] <mailto:[email-masked]>
> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 <https://tools.ietf.org/html/draft-jones-oauth-amr-values-03>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Jan 2016 15:37:09 -0500

Just reiterating my stance that this document detailing user authentication methods has no place in the OAuth working group.

 — Justin

> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi all,
>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jan 2016 17:43:34 -0300

I see your point that it is a fine line reporting how a person authenticated to a Authorization endpoit (it might be by SAML etc) and encouraging people to use OAuth for Authentication.

We already have the amr response in connect.  The only thing really missing is a registry.  Unless this is a sneaky way to get requested_amr into Connect?

John B.
> On Jan 20, 2016, at 5:37 PM, Justin Richer <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Jan 2016 21:29:18 +0000

The primary purpose of the specification is to establish a registry for "amr" JWT claim values.  This is important, as it increases interoperability among implementations using this claim.

It's a fair question whether "requested_amr" should be kept or dropped.  I agree with John and James that it's bad architecture.  I put it in the -00 individual draft to document existing practice.  I suspect that should the draft is adopted by the working group as a starting point, one of the first things the working group will want to decide is whether to drop it.  I suspect that I know how this will come out and I won't be sad, architecturally, to see it go.

As to whether this belongs in the OAuth working group, long ago it was decided that JWT and JWT claim definitions were within scope of the OAuth working group.  That ship has long ago sailed, both in terms of RFC 7519 and it continues to sail, for instance, in draft-ietf-oauth-proof-of-possession, which defines a new JWT claim, and is in the RFC Editor Queue.  Defining a registry for values of the "amr" claim, which is registered in the OAuth-established registry at http://www.iana.org/assignments/jwt, is squarely within the OAuth WG's mission for the creation and stewardship of JWT.

				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, January 20, 2016 12:44 PM
To: Justin Richer <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

John B.
>> You feedback will therefore be important to find out whether we 
>> should do this work in the OAuth working group.
>> 
>> Ciao
>> Hannes & Derek
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jan 2016 19:07:25 -0300

So if this is scoped to be a registry for the values of a JWT claim then it is fine.
We should discourage people from thinking that it is part of the OAuth protocol vs JWT claims.

John B.

> On Jan 20, 2016, at 6:29 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Jan 2016 18:00:59 -0500

As it’s currently written it’s not really limited to defining JWT claims, and so I’m with John that if that’s what this turns into and stays that way then it’s fine. I’m very afraid of scope creep and this being used for something it shouldn’t be.

And, as Mike well knows, I did not support the decision to bring JWT to this group, nor do I think we should be necessarily bound by the mistakes of the past when making future decisions of what to work on. :)

 — Justin

> On Jan 20, 2016, at 5:07 PM, John Bradley <[email-masked]> wrote:
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 20 Jan 2016 17:30:14 -0800

Right but OAuth is the layer that needs to relay the request to the authen service. 

+1 on adoption

However we need to discuss more on w this as a registry or how it is used in the overall architecture to pass signalling (hint maybe that falls to connect?) 

Phil

> On Jan 20, 2016, at 12:37, Justin Richer <[email-masked]> wrote:
>