[Openid-specs-ab] acr values

Mike Jones Michael.Jones at microsoft.com
Tue Aug 13 00:23:09 UTC 2013


The difference between "acr" and "amr" is that "acr", by design a single authentication class identifier, where as "amr" provides a list of method identifiers.

"acr" is really a statement about business relationships - i.e., "I, the OP, assert that the authentication performed meets the contractual requirements of level Silver in trust framework Foo".

"amr" is about saying what you did - i.e., "I the OP collected a password and verified an Oath OTP value generated by a hardware device".

They're different - intentionally.

Tim, it sounds to me like your RPs are actually asking for "amr" - not "acr".

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Pamela Dingle
Sent: Monday, August 12, 2013 5:10 PM
To: John Bradley
Cc: <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] acr values

+1.  NIST 800-63 tried to give people a rolled up value too.  I'm not sure that's something to strive for.  There are lots of relying parties who will care only about authentication methods and not policies.  And other relying parties who will care about policies but want to be agile about how those policies are executed.

I'm really excited that you're looking at pursuing this Tim, empowering a large number of Relying Parties to ask for more from their IDPs than a basic validation of an envelope is an exciting feature to offer, in my opinion!

Cheers,

Pam


On Mon, Aug 12, 2013 at 4:58 PM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
A single state value is useful but not so much if it turns into a text object describing the subjects entire life.   That is where many people went wrong in SAML


We currently have three things in connect:
acr which is a abstract identifier for the policy that the session conforms to.
amr a list of authentication methods used.
auth_time that can be used to determine the length of the session.

You can use the acr_values parameter to send an ordered list of the policies that the IdP should conform to, and the max_age parameter to force re-autentication if the limit is exceeded.
I think it was Google who was resisting having those parameters.

Having the RP ask for specific authentication methods rather than a more general policy is far to brittle outside of a small enterprise situation, that is why at the moment there is no amr_values parameter.

I think at the time all of this was being worked on Google had no interest to active opposition to parameters like max_age.   It might be worth reviewing them on a upcoming call to make sure we are all on the same page.   I guess from Mike's emai OX invented some other extensions to do similar things.


John B.

On 2013-08-12, at 5:45 PM, Tim Bray <tbray at textuality.com<mailto:tbray at textuality.com>> wrote:


On Mon, Aug 12, 2013 at 2:42 PM, Anthony Nadalin <tonynad at microsoft.com<mailto:tonynad at microsoft.com>> wrote:
I can see folks not wanting to look in multiple places and try to piece these together but want a single state value

Exactly right.

I agree with John that it's going to be tough to come up with something that will actually be helpful to RPs, but I'm getting weary of telling them "No, you shouldn't want that", so I think we're probably going to have to offer something, and I'm actively thinking about how best to communicate that in the OIDC framework.  -T



From: John Bradley [mailto:ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>]
Sent: Monday, August 12, 2013 1:59 PM
To: Tim Bray
Cc: Anthony Nadalin; <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>

Subject: Re: [Openid-specs-ab] acr values


There is already a auth_time claim.  Why would you want to try and overload it in acr.

auth_time
OPTIONAL or REQUIRED. Time when the End-User authentication occurred. The time is represented as the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED. (The auth_time Claim semantically corresponds to the OpenID 2.0 PAPE<http://openid.net/specs/openid-connect-messages-1_0.html#OpenID.PAPE> [OpenID.PAPE] auth_time response parameter.) The auth_time value is a number.

If you want to enumerate the factors used for primary authentication you would use:

amr
OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used. The definition of particular values to be used in the amrClaim is beyond the scope of this specification. Parties using this claim will need to agree upon the meanings of the values used, which may be context-specific. The amr value is an array of case sensitive strings.

Now I personally think that it is rare for a RP to actually be able to process the primary authentication info and make any sense out of it.   That was the experience in SAML everyone wanted it but it doesn't scale in the real world.

acr is a string, a collision resistent URI or string (There is a IANA registry).   It is intended to roll up a bunch of factors such as identity proofing account recovery security and authentication method into a single abstract value that a RP can make a decision on without requiring specific knowledge of the internal practices of the IdP.

I have seen people using the more detailed information break as soon as one of the IdP introduces a new method and every RP needs to update there code to deal with each change.

Token venders always want the RP to require a specific brand of token etc.  You can do it but it is not a good idea.

John B.


On 2013-08-12, at 4:45 PM, Tim Bray <tbray at textuality.com<mailto:tbray at textuality.com>> wrote:

An RP.

On Mon, Aug 12, 2013 at 1:30 PM, Anthony Nadalin <tonynad at microsoft.com<mailto:tonynad at microsoft.com>> wrote:
Who do you want to say something about the "session strength" to?

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of Tim Bray
Sent: Monday, August 12, 2013 1:05 PM
To: <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Subject: [Openid-specs-ab] acr values

In our IDP role, we're coming under a lot of pressure to say something about "session strength" and maybe in some circumstances force re-auth and so on.  There are a lot of different vocabularies in play that you could use to talk about this stuff, including NIST and ISO publications; and the work of the Fido alliance is maybe interesting.  So I expect a lot of churn in this space, and OIDC needs to allow sufficient elbow room.
So, the purpose of this note is to confirm my understandings, based on looking at the OIDC Messages draft.  Do people agree with these?
- It's perfectly OK to provide any old URI we dream up as a value for the "acr" claim.
- There may be awkwardness around multiple values; suppose I wanted to assert, for example, that the session is less than ten minutes old AND two-factor authent was used.    All I can think of is composing a URI along the lines of urn:google-auth-claims?max-age=10&two-factor=true; which is a little kludgy but I guess OK.  Awkward, though, in the case where there's a Fido vocabulary for 2-factor-flavor and someone else's vocabulary for session-freshness.

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab




_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab



--
Pamela Dingle  |  Sr. Technical Architect
PingIdentity  |   www.pingidentity.com<http://www.pingidentity.com>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
O: 303-999-5890   M: 303-999-5890
Email: pdingle at pingidentity.com<mailto:pdingle at pingidentity.com>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage

Connect with me
Twitter: @pamelarosiedee


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130813/f61b0bac/attachment-0001.html>


More information about the Openid-specs-ab mailing list