Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Mike Jones]

These were all added, per my other replies.

Thanks again,
-- Mike

From: Nat Sakimura [mailto:sakim...@gmail.com]
Sent: Sunday, July 26, 2015 4:03 PM
To: Brian Campbell
Cc: Mike Jones; William Denniss; 
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

I am in favor of William's proposal.
In addition, I would like to see one for 2nd channel auth, 2ch. That would 
indicate some resilience against MITB.

On Saturday, July 25, 2015, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
There's a method of authentication that is gaining in popularity which I'd 
propose adding a method for. It is typically used as a second factor where 
after a primary auth, like username and password, a push notification is sent 
to the user's phone and they acknowledge it from the device. We have the PingID 
product<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.pingidentity.com%2fen%2fproducts%2fpingid.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c1e014d22ad0a45a29ba208d295f52453%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kHpqzhIRYpbk7czSnWo14X%2fg25k7XeyMyZ0MpXL8Vwk%3d>
 that does it and 
Entrust<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.entrust.com%2fresource%2fentrust-identityguard-mobile-push-authentication-for-vpn-and-web-access&data=01%7c01%7cMichael.Jones%40microsoft.com%7c1e014d22ad0a45a29ba208d295f52453%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=D%2bKTzbh4BnaL5RxHdhMbWdE65yaZ8z0uBZj9mPk3BXI%3d>
 and 
Duo<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.duosecurity.com%2fproduct%2fmethods%2fduo-mobile&data=01%7c01%7cMichael.Jones%40microsoft.com%7c1e014d22ad0a45a29ba208d295f52453%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=t07t7CvtBkQBJ9%2boYkG3Ad5lFBB0DwrwDKOtXa2yACg%3d>,
 among others I'm sure, offer something similar.
It's commonly called "mobile push authentication" so maybe "mpa" could be the 
amr value. But, as Nat pointed out, the really interesting characteristic is 
that it's a second factor that utilizes only a secondary channel - so perhaps 
"sca" for "second channel authentication" would be a more appropriate general 
amr name.
Thoughts are welcome. But I believe it's becoming prevalent enough that it 
deserves its own amr value in this doc.



On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones 
>
 wrote:
I agree that an obvious good thing to do is to add spec references to the field 
definitions.

I need to investigate use cases for amr_values.  I think this came from 
developers who actually wanted this for a particular purpose but I’ll have to 
get back to the WG on that.  It’s defined here, rather than in another spec, 
because it’s highly related to the “amr” values.

-- Mike

From: OAuth 
[mailto:oauth-boun...@ietf.org]
 On Behalf Of Nat Sakimura
Sent: Thursday, July 23, 2015 6:22 PM
To: William Denniss
Cc: >
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

So, allow me a naive question.
I supppose there are good random otp, as well as pretty bad otp etc.
Would it be useful to say just "otp". Would it not be better to have at least a 
field that references a spec that specifies the security requirement for that 
mechanism?

2015-07-23 12:05 GMT+02:00 William Denniss 
>:
Thanks for drafting this Mike. I'm in favor of having this registry.

In addition to the specific values, I propose we add some generic ones too 
(trying to follow your naming scheme):

"rba":  "risk-based auth"
"upt":  "user presence test"

My fear of making things too specific is that RPs may get lost in the weeds 
trying to work out what things they should care about and how. As an IdP we 
like to guide RPs through these kinds of decisions, and prefer to pass a more 
high level indication of what happened (such as these two values).  If someone 
wanted to have best of both worlds, then both could be asserted, e.g. "upt fpt" 
to indicate that the user presence was tested, using a fingerprint test.

Regarding the proposed "wia" value. I don't know what it is, and the spec 
doesn't help me find out, can a reference be added?  I also wonder if it could 
be genericized to avoid being vendor specific values – but mostly I just want 
to understand what it is.  Almost all the other values are self-explanatory, 
perhaps "pop" could use a reference as well (or maybe just a longer 
explanation).

I don't see the immediate value of "amr_values", can you elaborate with some 
places where this would be applied?  Separately, I wonder if an extension to 
OIDC should be included in this doc

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Mike Jones]

I added this in -01 as “mca” (multiple-channel authentication).

Thanks,
-- Mike

From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Saturday, July 25, 2015 8:47 AM
To: Mike Jones
Cc: Nat Sakimura; William Denniss; 
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

There's a method of authentication that is gaining in popularity which I'd 
propose adding a method for. It is typically used as a second factor where 
after a primary auth, like username and password, a push notification is sent 
to the user's phone and they acknowledge it from the device. We have the PingID 
product<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.pingidentity.com%2fen%2fproducts%2fpingid.html&data=01%7c01%7cMichael.Jones%40microsoft.com%7c62c2764a6dc44f6c012e08d294ef266e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3Mq4ELCxwFiqefhqtW7Y4dqOto55FcvQT%2bJ9d1wNrMo%3d>
 that does it and 
Entrust<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.entrust.com%2fresource%2fentrust-identityguard-mobile-push-authentication-for-vpn-and-web-access&data=01%7c01%7cMichael.Jones%40microsoft.com%7c62c2764a6dc44f6c012e08d294ef266e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=kGHuPm%2bWy1Tg125loJhifmVow%2bMUE7L47wrRZD4%2f9jk%3d>
 and 
Duo<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.duosecurity.com%2fproduct%2fmethods%2fduo-mobile+&data=01%7c01%7cMichael.Jones%40microsoft.com%7c62c2764a6dc44f6c012e08d294ef266e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ax7nZLUqpCehO%2fMNqFGI56ZvzUgitk8Z2tT3mQ9V%2fco%3d>,
 among others I'm sure, offer something similar.
It's commonly called "mobile push authentication" so maybe "mpa" could be the 
amr value. But, as Nat pointed out, the really interesting characteristic is 
that it's a second factor that utilizes only a secondary channel - so perhaps 
"sca" for "second channel authentication" would be a more appropriate general 
amr name.
Thoughts are welcome. But I believe it's becoming prevalent enough that it 
deserves its own amr value in this doc.



On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
I agree that an obvious good thing to do is to add spec references to the field 
definitions.

I need to investigate use cases for amr_values.  I think this came from 
developers who actually wanted this for a particular purpose but I’ll have to 
get back to the WG on that.  It’s defined here, rather than in another spec, 
because it’s highly related to the “amr” values.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On 
Behalf Of Nat Sakimura
Sent: Thursday, July 23, 2015 6:22 PM
To: William Denniss
Cc: mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

So, allow me a naive question.
I supppose there are good random otp, as well as pretty bad otp etc.
Would it be useful to say just "otp". Would it not be better to have at least a 
field that references a spec that specifies the security requirement for that 
mechanism?

2015-07-23 12:05 GMT+02:00 William Denniss 
mailto:wdenn...@google.com>>:
Thanks for drafting this Mike. I'm in favor of having this registry.

In addition to the specific values, I propose we add some generic ones too 
(trying to follow your naming scheme):

"rba":  "risk-based auth"
"upt":  "user presence test"

My fear of making things too specific is that RPs may get lost in the weeds 
trying to work out what things they should care about and how. As an IdP we 
like to guide RPs through these kinds of decisions, and prefer to pass a more 
high level indication of what happened (such as these two values).  If someone 
wanted to have best of both worlds, then both could be asserted, e.g. "upt fpt" 
to indicate that the user presence was tested, using a fingerprint test.

Regarding the proposed "wia" value. I don't know what it is, and the spec 
doesn't help me find out, can a reference be added?  I also wonder if it could 
be genericized to avoid being vendor specific values – but mostly I just want 
to understand what it is.  Almost all the other values are self-explanatory, 
perhaps "pop" could use a reference as well (or maybe just a longer 
explanation).

I don't see the immediate value of "amr_values", can you elaborate with some 
places where this would be applied?  Separately, I wonder if an extension to 
OIDC should be included in this doc, which is otherwise a fairly clean registry 
spec that could be used more broadly.

On T

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Mike Jones]

I added references in a bunch of the definitions.  Please review them and 
suggest others, as appropriate.

-- Mike

From: Mike Jones
Sent: Thursday, July 23, 2015 12:29 PM
To: 'Nat Sakimura'; William Denniss
Cc: 
Subject: RE: [OAUTH-WG] Authentication Method Reference Values Specification

I agree that an obvious good thing to do is to add spec references to the field 
definitions.

I need to investigate use cases for amr_values.  I think this came from 
developers who actually wanted this for a particular purpose but I’ll have to 
get back to the WG on that.  It’s defined here, rather than in another spec, 
because it’s highly related to the “amr” values.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 23, 2015 6:22 PM
To: William Denniss
Cc: 
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

So, allow me a naive question.
I supppose there are good random otp, as well as pretty bad otp etc.
Would it be useful to say just "otp". Would it not be better to have at least a 
field that references a spec that specifies the security requirement for that 
mechanism?

2015-07-23 12:05 GMT+02:00 William Denniss 
mailto:wdenn...@google.com>>:
Thanks for drafting this Mike. I'm in favor of having this registry.

In addition to the specific values, I propose we add some generic ones too 
(trying to follow your naming scheme):

"rba":  "risk-based auth"
"upt":  "user presence test"

My fear of making things too specific is that RPs may get lost in the weeds 
trying to work out what things they should care about and how. As an IdP we 
like to guide RPs through these kinds of decisions, and prefer to pass a more 
high level indication of what happened (such as these two values).  If someone 
wanted to have best of both worlds, then both could be asserted, e.g. "upt fpt" 
to indicate that the user presence was tested, using a fingerprint test.

Regarding the proposed "wia" value. I don't know what it is, and the spec 
doesn't help me find out, can a reference be added?  I also wonder if it could 
be genericized to avoid being vendor specific values – but mostly I just want 
to understand what it is.  Almost all the other values are self-explanatory, 
perhaps "pop" could use a reference as well (or maybe just a longer 
explanation).

I don't see the immediate value of "amr_values", can you elaborate with some 
places where this would be applied?  Separately, I wonder if an extension to 
OIDC should be included in this doc, which is otherwise a fairly clean registry 
spec that could be used more broadly.

On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
So maybe a naive question but why does this draft define "amr_values" while 
also suggesting that it's fragile and that "acr" & "acr_values" is preferable? 
Seems contradictory. And I doubt I'm the only one that will find it confusing.

On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
The key part of this is establishing a registry.  That can only be done in an 
RFC.

John, I encourage you to submit text beefing up the arguments about why using 
“acr” is preferable.  The text at 
http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationship&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2blPSyG0xfBMg0jxKaQt1lAcW6GV3%2fje4dmkE%2bb7Q8o%3d>
 is a start at that.

        -- Mike

From: John Bradley [mailto:ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

I don’t personally have a problem with people defining values for AMR and 
creating a IANA registry.

That exists for ACR.

I am on record as not supporting clients requesting amr as it ai a bad idea and 
the spec mentions that at the same time it defines a new request parameter for 
it.

It is probably not something I will put any real effort into fighting, if 
people insist on it.  I will continue to recommend only using ACR in the 
request.

John B.

On Jul 23, 2015, at 9:21 AM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
parameter is defined?

 — Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones 

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Mike Jones]

Thanks, William.  These were added in -01 with the names “risk” and “user”.  I 
added references to a bunch of the definitions, including one for “wia”.

About “amr_values”, I did the investigation I’d promised about whether it was 
being used, and it is in production use by Azure Active Directory at present.  
Thus, I’ve left it in the spec at present.

-- Mike

From: William Denniss [mailto:wdenn...@google.com]
Sent: Thursday, July 23, 2015 6:05 AM
To: Brian Campbell
Cc: Mike Jones; 
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

Thanks for drafting this Mike. I'm in favor of having this registry.

In addition to the specific values, I propose we add some generic ones too 
(trying to follow your naming scheme):

"rba":  "risk-based auth"
"upt":  "user presence test"

My fear of making things too specific is that RPs may get lost in the weeds 
trying to work out what things they should care about and how. As an IdP we 
like to guide RPs through these kinds of decisions, and prefer to pass a more 
high level indication of what happened (such as these two values).  If someone 
wanted to have best of both worlds, then both could be asserted, e.g. "upt fpt" 
to indicate that the user presence was tested, using a fingerprint test.

Regarding the proposed "wia" value. I don't know what it is, and the spec 
doesn't help me find out, can a reference be added?  I also wonder if it could 
be genericized to avoid being vendor specific values – but mostly I just want 
to understand what it is.  Almost all the other values are self-explanatory, 
perhaps "pop" could use a reference as well (or maybe just a longer 
explanation).

I don't see the immediate value of "amr_values", can you elaborate with some 
places where this would be applied?  Separately, I wonder if an extension to 
OIDC should be included in this doc, which is otherwise a fairly clean registry 
spec that could be used more broadly.

On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
So maybe a naive question but why does this draft define "amr_values" while 
also suggesting that it's fragile and that "acr" & "acr_values" is preferable? 
Seems contradictory. And I doubt I'm the only one that will find it confusing.

On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
The key part of this is establishing a registry.  That can only be done in an 
RFC.

John, I encourage you to submit text beefing up the arguments about why using 
“acr” is preferable.  The text at 
http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationship&data=01%7c01%7cMichael.Jones%40microsoft.com%7cf74ac3a9b7384765ed3008d293464724%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6dyozSx3gxBo8T5sxI%2fb8jfeN%2bfXVv5Yt2mKTvHD7Z0%3d>
 is a start at that.

-- Mike

From: John Bradley [mailto:ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

I don’t personally have a problem with people defining values for AMR and 
creating a IANA registry.

That exists for ACR.

I am on record as not supporting clients requesting amr as it ai a bad idea and 
the spec mentions that at the same time it defines a new request parameter for 
it.

It is probably not something I will put any real effort into fighting, if 
people insist on it.  I will continue to recommend only using ACR in the 
request.

John B.

On Jul 23, 2015, at 9:21 AM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
parameter is defined?

 — Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Phil Hunt and I have posted a new draft that defines some values used with the 
“amr” (Authentication Methods References) claim and establishes a registry for 
Authentication Method Reference values.  These values include commonly used 
authentication methods like “pwd” (password) and “otp” (one time password).  It 
also defines a parameter for requesting that specific authentication methods be 
used in the authentication.

The specification is available at:
•
https://tools.ietf.org/html/draft-jones-oauth-amr-values-00<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-amr-values-00&data=01%7c01%7cMichael.Jones%40micro

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Nat Sakimura]

I am in favor of William's proposal.
In addition, I would like to see one for 2nd channel auth, 2ch. That would
indicate some resilience against MITB.

On Saturday, July 25, 2015, Brian Campbell 
wrote:

> There's a method of authentication that is gaining in popularity which I'd
> propose adding a method for. It is typically used as a second factor where
> after a primary auth, like username and password, a push notification is
> sent to the user's phone and they acknowledge it from the device. We have
> the PingID product <https://www.pingidentity.com/en/products/pingid.html>
> that does it and Entrust
> <http://www.entrust.com/resource/entrust-identityguard-mobile-push-authentication-for-vpn-and-web-access>
> and Duo <https://www.duosecurity.com/product/methods/duo-mobile>, among
> others I'm sure, offer something similar.
>
> It's commonly called "mobile push authentication" so maybe "mpa" could be
> the amr value. But, as Nat pointed out, the really interesting
> characteristic is that it's a second factor that utilizes only a secondary
> channel - so perhaps "sca" for "second channel authentication" would be a
> more appropriate general amr name.
>
> Thoughts are welcome. But I believe it's becoming prevalent enough that it
> deserves its own amr value in this doc.
>
>
>
>
> On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones  > wrote:
>
>>  I agree that an obvious good thing to do is to add spec references to
>> the field definitions.
>>
>>
>>
>> I need to investigate use cases for amr_values.  I think this came from
>> developers who actually wanted this for a particular purpose but I’ll have
>> to get back to the WG on that.  It’s defined here, rather than in another
>> spec, because it’s highly related to the “amr” values.
>>
>>
>>
>>                     -- Mike
>>
>>
>>
>> *From:* OAuth [mailto:oauth-boun...@ietf.org
>> ] *On Behalf Of *Nat
>> Sakimura
>> *Sent:* Thursday, July 23, 2015 6:22 PM
>> *To:* William Denniss
>> *Cc:* >
>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values
>> Specification
>>
>>
>>
>> So, allow me a naive question.
>>
>> I supppose there are good random otp, as well as pretty bad otp etc.
>>
>> Would it be useful to say just "otp". Would it not be better to have at
>> least a field that references a spec that specifies the security
>> requirement for that mechanism?
>>
>>
>>
>> 2015-07-23 12:05 GMT+02:00 William Denniss > >:
>>
>> Thanks for drafting this Mike. I'm in favor of having this registry.
>>
>>
>>
>> In addition to the specific values, I propose we add some generic ones
>> too (trying to follow your naming scheme):
>>
>>
>>
>> "rba":  "risk-based auth"
>>
>> "upt":  "user presence test"
>>
>>
>>
>> My fear of making things too specific is that RPs may get lost in the
>> weeds trying to work out what things they should care about and how. As an
>> IdP we like to guide RPs through these kinds of decisions, and prefer to
>> pass a more high level indication of what happened (such as these two
>> values).  If someone wanted to have best of both worlds, then both could be
>> asserted, e.g. "upt fpt" to indicate that the user presence was tested,
>> using a fingerprint test.
>>
>>
>>
>> Regarding the proposed "wia" value. I don't know what it is, and the spec
>> doesn't help me find out, can a reference be added?  I also wonder if it
>> could be genericized to avoid being vendor specific values – but mostly I
>> just want to understand what it is.  Almost all the other values are
>> self-explanatory, perhaps "pop" could use a reference as well (or maybe
>> just a longer explanation).
>>
>>
>>
>> I don't see the immediate value of "amr_values", can you elaborate with
>> some places where this would be applied?  Separately, I wonder if an
>> extension to OIDC should be included in this doc, which is otherwise a
>> fairly clean registry spec that could be used more broadly.
>>
>>
>>
>> On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell <
>> bcampb...@pingidentity.com
>> > wrote:
>>
>> So maybe a naive question but why does this draft define "amr_values"
>> while also suggesting that it's fragile and that &quo

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Brian Campbell]

There's a method of authentication that is gaining in popularity which I'd
propose adding a method for. It is typically used as a second factor where
after a primary auth, like username and password, a push notification is
sent to the user's phone and they acknowledge it from the device. We have
the PingID product <https://www.pingidentity.com/en/products/pingid.html>
that does it and Entrust
<http://www.entrust.com/resource/entrust-identityguard-mobile-push-authentication-for-vpn-and-web-access>
and Duo <https://www.duosecurity.com/product/methods/duo-mobile>, among
others I'm sure, offer something similar.

It's commonly called "mobile push authentication" so maybe "mpa" could be
the amr value. But, as Nat pointed out, the really interesting
characteristic is that it's a second factor that utilizes only a secondary
channel - so perhaps "sca" for "second channel authentication" would be a
more appropriate general amr name.

Thoughts are welcome. But I believe it's becoming prevalent enough that it
deserves its own amr value in this doc.




On Thu, Jul 23, 2015 at 6:29 PM, Mike Jones 
wrote:

>  I agree that an obvious good thing to do is to add spec references to
> the field definitions.
>
>
>
> I need to investigate use cases for amr_values.  I think this came from
> developers who actually wanted this for a particular purpose but I’ll have
> to get back to the WG on that.  It’s defined here, rather than in another
> spec, because it’s highly related to the “amr” values.
>
>
>
> -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *Nat Sakimura
> *Sent:* Thursday, July 23, 2015 6:22 PM
> *To:* William Denniss
> *Cc:* 
> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values
> Specification
>
>
>
> So, allow me a naive question.
>
> I supppose there are good random otp, as well as pretty bad otp etc.
>
> Would it be useful to say just "otp". Would it not be better to have at
> least a field that references a spec that specifies the security
> requirement for that mechanism?
>
>
>
> 2015-07-23 12:05 GMT+02:00 William Denniss :
>
> Thanks for drafting this Mike. I'm in favor of having this registry.
>
>
>
> In addition to the specific values, I propose we add some generic ones too
> (trying to follow your naming scheme):
>
>
>
> "rba":  "risk-based auth"
>
> "upt":  "user presence test"
>
>
>
> My fear of making things too specific is that RPs may get lost in the
> weeds trying to work out what things they should care about and how. As an
> IdP we like to guide RPs through these kinds of decisions, and prefer to
> pass a more high level indication of what happened (such as these two
> values).  If someone wanted to have best of both worlds, then both could be
> asserted, e.g. "upt fpt" to indicate that the user presence was tested,
> using a fingerprint test.
>
>
>
> Regarding the proposed "wia" value. I don't know what it is, and the spec
> doesn't help me find out, can a reference be added?  I also wonder if it
> could be genericized to avoid being vendor specific values – but mostly I
> just want to understand what it is.  Almost all the other values are
> self-explanatory, perhaps "pop" could use a reference as well (or maybe
> just a longer explanation).
>
>
>
> I don't see the immediate value of "amr_values", can you elaborate with
> some places where this would be applied?  Separately, I wonder if an
> extension to OIDC should be included in this doc, which is otherwise a
> fairly clean registry spec that could be used more broadly.
>
>
>
> On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
> So maybe a naive question but why does this draft define "amr_values"
> while also suggesting that it's fragile and that "acr" & "acr_values" is
> preferable? Seems contradictory. And I doubt I'm the only one that will
> find it confusing.
>
>
>
> On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones 
> wrote:
>
> The key part of this is establishing a registry.  That can only be done in
> an RFC.
>
>
>
> John, I encourage you to submit text beefing up the arguments about why
> using “acr” is preferable.  The text at
> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationshi

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Mike Jones]

I agree that an obvious good thing to do is to add spec references to the field 
definitions.

I need to investigate use cases for amr_values.  I think this came from 
developers who actually wanted this for a particular purpose but I’ll have to 
get back to the WG on that.  It’s defined here, rather than in another spec, 
because it’s highly related to the “amr” values.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, July 23, 2015 6:22 PM
To: William Denniss
Cc: 
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

So, allow me a naive question.
I supppose there are good random otp, as well as pretty bad otp etc.
Would it be useful to say just "otp". Would it not be better to have at least a 
field that references a spec that specifies the security requirement for that 
mechanism?

2015-07-23 12:05 GMT+02:00 William Denniss 
mailto:wdenn...@google.com>>:
Thanks for drafting this Mike. I'm in favor of having this registry.

In addition to the specific values, I propose we add some generic ones too 
(trying to follow your naming scheme):

"rba":  "risk-based auth"
"upt":  "user presence test"

My fear of making things too specific is that RPs may get lost in the weeds 
trying to work out what things they should care about and how. As an IdP we 
like to guide RPs through these kinds of decisions, and prefer to pass a more 
high level indication of what happened (such as these two values).  If someone 
wanted to have best of both worlds, then both could be asserted, e.g. "upt fpt" 
to indicate that the user presence was tested, using a fingerprint test.

Regarding the proposed "wia" value. I don't know what it is, and the spec 
doesn't help me find out, can a reference be added?  I also wonder if it could 
be genericized to avoid being vendor specific values – but mostly I just want 
to understand what it is.  Almost all the other values are self-explanatory, 
perhaps "pop" could use a reference as well (or maybe just a longer 
explanation).

I don't see the immediate value of "amr_values", can you elaborate with some 
places where this would be applied?  Separately, I wonder if an extension to 
OIDC should be included in this doc, which is otherwise a fairly clean registry 
spec that could be used more broadly.

On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell 
mailto:bcampb...@pingidentity.com>> wrote:
So maybe a naive question but why does this draft define "amr_values" while 
also suggesting that it's fragile and that "acr" & "acr_values" is preferable? 
Seems contradictory. And I doubt I'm the only one that will find it confusing.

On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:
The key part of this is establishing a registry.  That can only be done in an 
RFC.

John, I encourage you to submit text beefing up the arguments about why using 
“acr” is preferable.  The text at 
http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-00.html%23acrRelationship&data=01%7c01%7cMichael.Jones%40microsoft.com%7c45f73eec59c2463664de08d2937adf52%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6%2blPSyG0xfBMg0jxKaQt1lAcW6GV3%2fje4dmkE%2bb7Q8o%3d>
 is a start at that.

-- Mike

From: John Bradley [mailto:ve7...@ve7jtb.com<mailto:ve7...@ve7jtb.com>]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

I don’t personally have a problem with people defining values for AMR and 
creating a IANA registry.

That exists for ACR.

I am on record as not supporting clients requesting amr as it ai a bad idea and 
the spec mentions that at the same time it defines a new request parameter for 
it.

It is probably not something I will put any real effort into fighting, if 
people insist on it.  I will continue to recommend only using ACR in the 
request.

John B.

On Jul 23, 2015, at 9:21 AM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
parameter is defined?

 — Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Phil Hunt and I have posted a new draft that defines some values used with the 
“amr” (Authentication Methods References) claim and establishes a registry for 
Authentication Method Reference values.  These values include commonly used 
authentication methods like “pwd” (password) and “otp” (one time passw

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Nat Sakimura]

So, allow me a naive question.
I supppose there are good random otp, as well as pretty bad otp etc.
Would it be useful to say just "otp". Would it not be better to have at
least a field that references a spec that specifies the security
requirement for that mechanism?

2015-07-23 12:05 GMT+02:00 William Denniss :

> Thanks for drafting this Mike. I'm in favor of having this registry.
>
> In addition to the specific values, I propose we add some generic ones too
> (trying to follow your naming scheme):
>
> "rba":  "risk-based auth"
> "upt":  "user presence test"
>
> My fear of making things too specific is that RPs may get lost in the
> weeds trying to work out what things they should care about and how. As an
> IdP we like to guide RPs through these kinds of decisions, and prefer to
> pass a more high level indication of what happened (such as these two
> values).  If someone wanted to have best of both worlds, then both could be
> asserted, e.g. "upt fpt" to indicate that the user presence was tested,
> using a fingerprint test.
>
> Regarding the proposed "wia" value. I don't know what it is, and the spec
> doesn't help me find out, can a reference be added?  I also wonder if it
> could be genericized to avoid being vendor specific values – but mostly I
> just want to understand what it is.  Almost all the other values are
> self-explanatory, perhaps "pop" could use a reference as well (or maybe
> just a longer explanation).
>
> I don't see the immediate value of "amr_values", can you elaborate with
> some places where this would be applied?  Separately, I wonder if an
> extension to OIDC should be included in this doc, which is otherwise a
> fairly clean registry spec that could be used more broadly.
>
> On Thu, Jul 23, 2015 at 10:49 AM, Brian Campbell <
> bcampb...@pingidentity.com> wrote:
>
>> So maybe a naive question but why does this draft define "amr_values"
>> while also suggesting that it's fragile and that "acr" & "acr_values" is
>> preferable? Seems contradictory. And I doubt I'm the only one that will
>> find it confusing.
>>
>> On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones 
>> wrote:
>>
>>>  The key part of this is establishing a registry.  That can only be
>>> done in an RFC.
>>>
>>>
>>>
>>> John, I encourage you to submit text beefing up the arguments about why
>>> using “acr” is preferable.  The text at
>>> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship
>>> is a start at that.
>>>
>>>
>>>
>>> -- Mike
>>>
>>>
>>>
>>> *From:* John Bradley [mailto:ve7...@ve7jtb.com]
>>> *Sent:* Thursday, July 23, 2015 9:30 AM
>>> *To:* Justin Richer
>>> *Cc:* Mike Jones; 
>>> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values
>>> Specification
>>>
>>>
>>>
>>> I don’t personally have a problem with people defining values for AMR
>>> and creating a IANA registry.
>>>
>>>
>>>
>>> That exists for ACR.
>>>
>>>
>>>
>>> I am on record as not supporting clients requesting amr as it ai a bad
>>> idea and the spec mentions that at the same time it defines a new request
>>> parameter for it.
>>>
>>>
>>>
>>> It is probably not something I will put any real effort into fighting,
>>> if people insist on it.  I will continue to recommend only using ACR in the
>>> request.
>>>
>>>
>>>
>>> John B.
>>>
>>>
>>>
>>>  On Jul 23, 2015, at 9:21 AM, Justin Richer  wrote:
>>>
>>>
>>>
>>> Useful work, but shouldn’t this be defined in the OIDF, where the “amr"
>>> parameter is defined?
>>>
>>>
>>>
>>>  — Justin
>>>
>>>
>>>
>>>  On Jul 22, 2015, at 7:48 PM, Mike Jones 
>>> wrote:
>>>
>>>
>>>
>>> Phil Hunt and I have posted a new draft that defines some values used
>>> with the “amr” (Authentication Methods References) claim and
>>> establishes a registry for Authentication Method Reference values.  These
>>> values include commonly used authentication methods like “pwd”
>>> (password) and “otp” (one time password).  It also defines a parameter
>>> for requesting that specif

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Phil Hunt]

I do tend to agree John that clients shouldn't be able to force the sp on 
choices. 

My thought was that it was useful to have a registry so we can have standard 
auth method values for protocols that get written like oidc.  It may be useful 
elsewhere. 

Anyway as a general rule I think it is sometimes useful for a client to signal 
a preference or capability in order that the server can make a good choice that 
meets its own needs. 

Phil

> On Jul 23, 2015, at 09:30, John Bradley  wrote:
> 
> I don’t personally have a problem with people defining values for AMR and 
> creating a IANA registry. 
> 
> That exists for ACR.
> 
> I am on record as not supporting clients requesting amr as it ai a bad idea 
> and the spec mentions that at the same time it defines a new request 
> parameter for it.
> 
> It is probably not something I will put any real effort into fighting, if 
> people insist on it.  I will continue to recommend only using ACR in the 
> request.
> 
> John B.
> 
>> On Jul 23, 2015, at 9:21 AM, Justin Richer  wrote:
>> 
>> Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
>> parameter is defined?
>> 
>>  — Justin
>> 
>>> On Jul 22, 2015, at 7:48 PM, Mike Jones  wrote:
>>> 
>>> Phil Hunt and I have posted a new draft that defines some values used with 
>>> the “amr” (Authentication Methods References) claim and establishes a 
>>> registry for Authentication Method Reference values.  These values include 
>>> commonly used authentication methods like “pwd” (password) and “otp” (one 
>>> time password).  It also defines a parameter for requesting that specific 
>>> authentication methods be used in the authentication.
>>>  
>>> The specification is available at:
>>> ·https://tools.ietf.org/html/draft-jones-oauth-amr-values-00
>>>  
>>> An HTML formatted version is also available at:
>>> ·http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html
>>>  
>>> -- Mike
>>>  
>>> P.S.  This note was also posted at http://self-issued.info/?p=1429 and as 
>>> @selfissued.
>>> ___
>>> 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

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Brian Campbell]

So maybe a naive question but why does this draft define "amr_values" while
also suggesting that it's fragile and that "acr" & "acr_values" is
preferable? Seems contradictory. And I doubt I'm the only one that will
find it confusing.

On Thu, Jul 23, 2015 at 9:35 AM, Mike Jones 
wrote:

>  The key part of this is establishing a registry.  That can only be done
> in an RFC.
>
>
>
> John, I encourage you to submit text beefing up the arguments about why
> using “acr” is preferable.  The text at
> http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship
> is a start at that.
>
>
>
> -- Mike
>
>
>
> *From:* John Bradley [mailto:ve7...@ve7jtb.com]
> *Sent:* Thursday, July 23, 2015 9:30 AM
> *To:* Justin Richer
> *Cc:* Mike Jones; 
> *Subject:* Re: [OAUTH-WG] Authentication Method Reference Values
> Specification
>
>
>
> I don’t personally have a problem with people defining values for AMR and
> creating a IANA registry.
>
>
>
> That exists for ACR.
>
>
>
> I am on record as not supporting clients requesting amr as it ai a bad
> idea and the spec mentions that at the same time it defines a new request
> parameter for it.
>
>
>
> It is probably not something I will put any real effort into fighting, if
> people insist on it.  I will continue to recommend only using ACR in the
> request.
>
>
>
> John B.
>
>
>
>  On Jul 23, 2015, at 9:21 AM, Justin Richer  wrote:
>
>
>
> Useful work, but shouldn’t this be defined in the OIDF, where the “amr"
> parameter is defined?
>
>
>
>  — Justin
>
>
>
>  On Jul 22, 2015, at 7:48 PM, Mike Jones 
> wrote:
>
>
>
> Phil Hunt and I have posted a new draft that defines some values used with
> the “amr” (Authentication Methods References) claim and establishes a
> registry for Authentication Method Reference values.  These values include
> commonly used authentication methods like “pwd” (password) and “otp” (one
> time password).  It also defines a parameter for requesting that specific
> authentication methods be used in the authentication.
>
>
>
> The specification is available at:
>
> ·https://tools.ietf.org/html/draft-jones-oauth-amr-values-00
>
>
>
> An HTML formatted version is also available at:
>
> ·http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html
>
>
>
> -- Mike
>
>
>
> P.S.  This note was also posted at http://self-issued.info/?p=1429 and as
> @selfissued <https://twitter.com/selfissued>.
>
> ___
> 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

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Mike Jones]

The key part of this is establishing a registry.  That can only be done in an 
RFC.

John, I encourage you to submit text beefing up the arguments about why using 
“acr” is preferable.  The text at 
http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html#acrRelationship
 is a start at that.

-- Mike

From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Thursday, July 23, 2015 9:30 AM
To: Justin Richer
Cc: Mike Jones; 
Subject: Re: [OAUTH-WG] Authentication Method Reference Values Specification

I don’t personally have a problem with people defining values for AMR and 
creating a IANA registry.

That exists for ACR.

I am on record as not supporting clients requesting amr as it ai a bad idea and 
the spec mentions that at the same time it defines a new request parameter for 
it.

It is probably not something I will put any real effort into fighting, if 
people insist on it.  I will continue to recommend only using ACR in the 
request.

John B.

On Jul 23, 2015, at 9:21 AM, Justin Richer 
mailto:jric...@mit.edu>> wrote:

Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
parameter is defined?

 — Justin

On Jul 22, 2015, at 7:48 PM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

Phil Hunt and I have posted a new draft that defines some values used with the 
“amr” (Authentication Methods References) claim and establishes a registry for 
Authentication Method Reference values.  These values include commonly used 
authentication methods like “pwd” (password) and “otp” (one time password).  It 
also defines a parameter for requesting that specific authentication methods be 
used in the authentication.

The specification is available at:
•https://tools.ietf.org/html/draft-jones-oauth-amr-values-00

An HTML formatted version is also available at:
•http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html

-- Mike

P.S.  This note was also posted at http://self-issued.info/?p=1429 and as 
@selfissued<https://twitter.com/selfissued>.
___
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

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[John Bradley]

I don’t personally have a problem with people defining values for AMR and 
creating a IANA registry. 

That exists for ACR.

I am on record as not supporting clients requesting amr as it ai a bad idea and 
the spec mentions that at the same time it defines a new request parameter for 
it.

It is probably not something I will put any real effort into fighting, if 
people insist on it.  I will continue to recommend only using ACR in the 
request.

John B.

> On Jul 23, 2015, at 9:21 AM, Justin Richer  wrote:
> 
> Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
> parameter is defined?
> 
>  — Justin
> 
>> On Jul 22, 2015, at 7:48 PM, Mike Jones > > wrote:
>> 
>> Phil Hunt and I have posted a new draft that defines some values used with 
>> the “amr” (Authentication Methods References) claim and establishes a 
>> registry for Authentication Method Reference values.  These values include 
>> commonly used authentication methods like “pwd” (password) and “otp” (one 
>> time password).  It also defines a parameter for requesting that specific 
>> authentication methods be used in the authentication.
>>  
>> The specification is available at:
>> ·https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 
>> 
>>  
>> An HTML formatted version is also available at:
>> ·http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html 
>> 
>>  
>> -- Mike
>>  
>> P.S.  This note was also posted at http://self-issued.info/?p=1429 
>>  and as @selfissued 
>> .
>> ___
>> 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 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authentication Method Reference Values Specification

[Justin Richer]

Useful work, but shouldn’t this be defined in the OIDF, where the “amr" 
parameter is defined?

 — Justin

> On Jul 22, 2015, at 7:48 PM, Mike Jones  wrote:
> 
> Phil Hunt and I have posted a new draft that defines some values used with 
> the “amr” (Authentication Methods References) claim and establishes a 
> registry for Authentication Method Reference values.  These values include 
> commonly used authentication methods like “pwd” (password) and “otp” (one 
> time password).  It also defines a parameter for requesting that specific 
> authentication methods be used in the authentication.
>  
> The specification is available at:
> ·https://tools.ietf.org/html/draft-jones-oauth-amr-values-00 
> 
>  
> An HTML formatted version is also available at:
> ·http://self-issued.info/docs/draft-jones-oauth-amr-values-00.html 
> 
>  
> -- Mike
>  
> P.S.  This note was also posted at http://self-issued.info/?p=1429 
>  and as @selfissued 
> .
> ___
> 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