[Openid-specs-ab] amr vs acr

Torsten Lodderstedt torsten at lodderstedt.net
Mon Jun 3 08:59:01 UTC 2013


 

Hi Nat, 

we traditionally indicate all authentication classes
fullfilled by a particular session/login transaction to our RPs, no
matter whether the RP requested a certain class or not. We would like to
keep it that way. 

Having said that, I would like to understand how you
(and the WG) envision the usage of acrs. Does an acr response only make
sense, if the RP explicitely requested and or more acrs? So is the acr
only used to confirm the fullfillment of a RP's requirement to a certain
login transaction? 

regards,
Torsten. 

Am 03.06.2013 01:04, schrieb
Nat Sakimura: 

> Torsten, 
> 
> What is your use case for multi valued
acr response? 
> 
> FYI, a client can 'request' multiple acr values. 
>
The server, if it can fulfill, picks one and responds. 
> 
> 2013/6/1
Torsten Lodderstedt <torsten at lodderstedt.net>
> 
>> Hi Mike, 
>> 
>> can
you still remember the arguments? I couldn't find a note about this
discussion in the respective minutes
(http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130304/003231.html
[1]). 
>> 
>> regards, 
>> Torsten. 
>> 
>> Am 01.06.2013 um 15:25
schrieb Mike Jones <Michael.Jones at microsoft.com>:
>> 
>>> Having a
multi-valued "acr" was what the issue originally proposed. John, Nat,
and I think Tony all argued in the March 4th call that that was the
wrong thing to do. They convinced me that they're right. 
>>> 
>>> --
Mike 
>>> 
>>> FROM: Torsten Lodderstedt
[mailto:torsten at lodderstedt.net] 
>>> SENT: Friday, May 31, 2013 11:26
PM
>>> TO: Mike Jones
>>> CC: John Bradley; OpenId Connect List
>>>
SUBJECT: Re: [Openid-specs-ab] amr vs acr 
>>> 
>>> Hi, 
>>> 
>>> seems
no one is really comfortable with the current design. Why not drop amr
and make acr a multi-value? 
>>> 
>>> regards, 
>>> 
>>> Torsten. 
>>>

>>> Am 01.06.2013 um 03:55 schrieb Mike Jones
<Michael.Jones at microsoft.com>: 
>>> 
>>>> That aligns with my thinking
as well. 
>>>> 
>>>> FROM: John Bradley [mailto:ve7jtb at ve7jtb.com] 
>>>>
SENT: Friday, May 31, 2013 6:54 PM
>>>> TO: Mike Jones
>>>> CC: Nat
Sakimura; OpenId Connect List
>>>> SUBJECT: Re: [Openid-specs-ab] amr vs
acr 
>>>> 
>>>> amr is something people think they want, but it winds up
being too inflexible for any real use. Mostly it is token venders that
push it. Once an IdP starts saying the user was authenticated wit brand
x token or card it is too difficult to keep a federation in sync unless
it is quite small. 
>>>> 
>>>> act is a good level of abstraction and
can cover all the real use cases I know of. 
>>>> 
>>>> On the other
hand amr will let people learn the mistakes of SAML over again. 
>>>>

>>>> It is not the end of the world to have it as an option. 
>>>>

>>>> Sent from my iPhone 
>>>> 
>>>> On 2013-05-31, at 10:19 PM, Mike
Jones <Michael.Jones at microsoft.com> wrote: 
>>>> 
>>>>> I disagree with
the MUSTs. We already have language in place saying that if claims
aren't understood, they should be ignored, so there's no actual problem.
(Were there a problem, it would apply to "acr" as well.) 
>>>>> 
>>>>> I
could see going as far as saying, in both "acr" and "amr" that "The
definition of particular values to be used in the acr/amr Claim is
beyond the scope of this specification. Parties using this claim will
need to agree on the meanings of the values used for it to be useful to
them." 
>>>>> 
>>>>> -- Mike 
>>>>> 
>>>>> FROM: Nat Sakimura
[mailto:sakimura at gmail.com] 
>>>>> SENT: Friday, May 31, 2013 6:06
PM
>>>>> TO: Mike Jones
>>>>> CC: Torsten Lodderstedt; OpenId Connect
List
>>>>> SUBJECT: Re: [Openid-specs-ab] amr vs acr 
>>>>> 
>>>>> Ah,
that's the call in the morning of the JICS that you did in the 11th
floor of NII. 
>>>>> 
>>>>> I came in late, sitting at a different table
that hearing to the call was a bit hard but did not mind as I was very
much distracted by various things to be dealt with JICS. 
>>>>> 
>>>>> I
remember talking about changing 1,2,3,4 as it became non-compliant to
the RFC, as well as arguing against conflating authentication method
with the authentication class, on the basis that authentication method
by itself is useless and harmful, as in the previous mail. I mistakingly
thought that I have killed the idea of amr, which apparently was not.

>>>>> 
>>>>> Unfortunately, the discussion is not recorded in
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130304/003231.html
[1] . 
>>>>> 
>>>>> Probably, we should add some warning text to amr
then. At the end of the definition of arm, how about adding the
following? 
>>>>> 
>>>>> When using amr, the RP and OP MUST define the
common context including the meaning, security characteristics, and the
compliance requirement for using it and the RP MUST be able to evaluate
the values according to the defined context. 
>>>>> 
>>>>> That would
mitigate my worries. 
>>>>> 
>>>>> 2013/6/1 Mike Jones
<Michael.Jones at microsoft.com> 
>>>>> 
>>>>> This was one of the two open
issues discussed on the 4-Mar-13 working group call. You were on that
call, according to the minutes. We had a fairly extensive discussion
about the meaning of "acr" and the right way to return information about
authentication methods used. Originally the request was to allow
multi-valued "acr" values. There was a use case where an implementation
wanted to communicate the actual methods used such as "password", "OTP",
"code in text message", etc. and I'd originally advocated for letting
"acr" be multi-valued, just like PAPE did. John, Tony, and I think you
convinced us that that conflating classes with methods would create more
problems than it would solve and that it was better to define an
optional claim for returning an array of methods used, when needed.

>>>>> 
>>>>> On that call we also deleted the LoA values "1", "2", "3",
and "4" since as part of that discussion, it came up that they are
prohibited by RFC 6711. Instead, we replaced the example values used
with real values from InCommon - urn:mace:incommon:iap:bronze and
urn:mace:incommon:iap:silver. 
>>>>> 
>>>>> I don't think that we should
require "acr" when "amr" is used, because there may not be a class, even
though there are methods. It depends upon the business context in which
the parties are communicating. Like "acr", "amr" is only useful when the
values are understood by both parties. Nonetheless, it's better to have
a standard claim for these methods than to have everyone make up a
different one. This kind of information is used in practice, in some
contexts. 
>>>>> 
>>>>> -- Mike 
>>>>> 
>>>>> FROM:
openid-specs-ab-bounces at lists.openid.net
[mailto:openid-specs-ab-bounces at lists.openid.net] ON BEHALF OF Nat
Sakimura
>>>>> SENT: Friday, May 31, 2013 4:53 PM
>>>>> TO: Torsten
Lodderstedt
>>>>> CC: OpenId Connect List
>>>>> SUBJECT: Re:
[Openid-specs-ab] amr vs acr 
>>>>> 
>>>>> s/ where acr gives more
context to the values of acr. / where acr gives more context to the
values of amr. / 
>>>>> 
>>>>> 2013/6/1 Nat Sakimura
<sakimura at gmail.com> 
>>>>> 
>>>>> I suppose you mean amr, not acm.

>>>>> 
>>>>> I actually was not aware of amr till now. It seems it was
a fairly quick decision made between March 4 and 6. 
>>>>> 
>>>>> See
https://bitbucket.org/openid/connect/issue/789/make-acr-claim-values-be-arrays-of-acr
[2] 
>>>>> 
>>>>> At the time, I was so busy managing JICS 2013, so it
went unnoticed for me. 
>>>>> 
>>>>> I also searched through the list
archive, but I cannot find the topic in it. There is no record of the
decision on the call notes either. 
>>>>> 
>>>>> Mike, could you point
us to the record how the WG decision was reached? 
>>>>> 
>>>>>
Apparently, amr is the list of authentication methods, while acr is the
indicator of the identity proofing and authentication quality. 
>>>>>

>>>>> i.e., amr is just the list of such things like "password", "otp",
etc. while acr is "InCommons Silver", "ISO29115 LoA 3", etc. 
>>>>>

>>>>> Personally, I do not see much value in amr since it does not
indicate any quality information. It may even be harmful when used
without context in the sense that it may create sense of false security
to the relying parties. For example, "otp" by itself does not mean it is
secure. An OTP system with badly managed seed will generate a
predictable sequence of "one time passwords", which is not secure at
all. It would only be meaningful when there is an assurance that the
system is properly managed. In this respect, amr may be meaningful as an
auxiliary information only when it is used with acr, where acr gives
more context to the values of acr. 
>>>>> 
>>>>> I might want to require
acr if amr is used, or drop amr, but that is only my personal opinion.

>>>>> 
>>>>> 2013/6/1 Torsten Lodderstedt <torsten at lodderstedt.net>

>>>>> 
>>>>> Hi,
>>>>> 
>>>>> could someone please describe me the
difference between the id token members acr and acm? From my
understanding, they are just the same. I'm also interested to learn why
the authorization request allows to specify multiple acrs but does not
support to specify any authentication method (via acm). Additionally,
why is there no way to indicate more than one acr in the id token?
>>>>>

>>>>> Thanks in advance,
>>>>> Torsten.
>>>>>
_______________________________________________
>>>>> Openid-specs-ab
mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3] 
>>>>>

>>>>> -- 
>>>>> Nat Sakimura (=nat) 
>>>>> 
>>>>> Chairman, OpenID
Foundation
>>>>> http://nat.sakimura.org/ [4]
>>>>> @_nat_en 
>>>>>

>>>>> -- 
>>>>> Nat Sakimura (=nat) 
>>>>> 
>>>>> Chairman, OpenID
Foundation
>>>>> http://nat.sakimura.org/ [4]
>>>>> @_nat_en 
>>>>>

>>>>> -- 
>>>>> Nat Sakimura (=nat) 
>>>>> 
>>>>> Chairman, OpenID
Foundation
>>>>> http://nat.sakimura.org/ [4]
>>>>> @_nat_en
>>>> 
>>>>>
_______________________________________________
>>>>> Openid-specs-ab
mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3]
>>> 
>>>>
_______________________________________________
>>>> Openid-specs-ab
mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3]
>> 
>>
_______________________________________________
>> Openid-specs-ab
mailing list
>> Openid-specs-ab at lists.openid.net
>>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3]
> 
> -- 
>
Nat Sakimura (=nat) 
> Chairman, OpenID Foundation
>
http://nat.sakimura.org/ [4]
> @_nat_en

 

Links:
------
[1]
http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20130304/003231.html
[2]
https://bitbucket.org/openid/connect/issue/789/make-acr-claim-values-be-arrays-of-acr
[3]
http://lists.openid.net/mailman/listinfo/openid-specs-ab
[4]
http://nat.sakimura.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130603/71a0df35/attachment-0001.html>


More information about the Openid-specs-ab mailing list