[Openid-specs-ab] acr text

Mike Jones Michael.Jones at microsoft.com
Sun Jun 2 23:19:24 UTC 2013

I could live with this:

3) SHOULD with MUST NOT use the values in the registry defined by RFC6711 with different meanings.

Yes, you're right Nat that we're talking about claims values, not claim names in this case.  But the principle is the same.  Normally, registered or collision-resistant names should be used.  But "between consenting implementations", there's nothing wrong with using private names, any more than there is anything wrong with using private claim names.  Yes collisions could eventually result.  But that's the risk that people using private names are knowingly taking.

If we weren't in a space-constrained environment, I wouldn't have any problem with a MUST.  But we are, so brevity is essential, and absolute URIs are far from brief.  We should therefore never have a MUST that effectively requires their use.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura at gmail.com]
Sent: Sunday, June 02, 2013 4:01 PM
To: John Bradley
Cc: Mike Jones; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] acr text

+1, in as much as I do not want people to use RS256 with other private meanings in JWS.

My preference.

2) SHOULD with MUST NOT use the values defined in RFC6711.

As I stated before, 2) is rather difficult to implement. It requires the developers to pull RFC6711 registry every time it requests / responds a private acr value. IMHO, 1) is the way to go.

2013/6/3 John Bradley <jbradley at pingidentity.com<mailto:jbradley at pingidentity.com>>
I prefer the value to be a URI unless a registered name is used.  That prevents collisions and configuration errors.    I don't think making a private name a URI is overly restrictive.

It needs to at least be a SHOULD perhaps with a warning about use of unregistered short names being dangerous outside of testing due to possible name collisions.

It doesn't take much to do the registration.   I prefer to keep it tight and not have lots of people using values like "3" all with separate definitions.

John Bradley  |  Sr. Technical Architect
Ping Identity  |   www.pingidentity.com<http://www.pingidentity.com/>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
O: +1 720.306.6055<tel:%2B1%20720.306.6055>   M: +1 (303) 396-9546
Email: jbradley at pingidentity.com<mailto:jbradley at pingidentity.com>

- - - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - -

Join me at Cloud Identity Summit
Twitter: @CloudIDSummit<http://twitter.com/#!/@CloudIDSummit>

   Connect with me
   Twitter: @<http://twitter.com/#!/@user_name>ve7jtb

On 2013-06-02, at 11:36 PM, Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>> wrote:

A must wouldn't be consistent with the rest of how we use claims.  Where two parties have a private agreement on the meanings of claims, we allow the use of private, unregistered names, perhttp://tools.ietf.org/html/draft-ietf-oauth-json-web-token-08#section-4.3.  I don't think we should absolutely mandate the use of registered names in this case, when we don't anywhere else.

Also, some trust frameworks may experiment with a name before deciding that it's time to register it.  We shouldn't make that illegal.

A "SHOULD" is fine.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net> [mailto:openid-<mailto:openid->specs-ab-bounces at lists.openid.net<mailto:specs-ab-bounces at lists.openid.net>] On Behalf Of Nat Sakimura
Sent: Sunday, June 02, 2013 2:31 PM
To: Bradley John; openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>
Subject: [Openid-specs-ab] acr text

Especially to John,

acr text says:

 An absolute URI or a registered name<http://openid.bitbucket.org/openid-connect-messages-1_0.html#RFC6711> [RFC6711] MAY be used as an acr value.

Is it really MAY? Is it not MUST?

Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>

Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130602/617949fc/attachment-0001.html>

More information about the Openid-specs-ab mailing list