[Openid-specs-ab] acr text

Nat Sakimura sakimura at gmail.com
Mon Jun 3 17:21:38 UTC 2013


Ok with 3). You need to record this thread to the ticket though. Just a
copy and paste would do.


2013/6/3 John Bradley <jbradley at pingidentity.com>

> That is OK,  I don't think it requires run time checking of the registry,
>  it is more a rule that can be used in disputes on what is correct.
>
>
> *John Bradley*  |  Sr. Technical Architect
> *Ping* *Identity*  |   www.pingidentity.com
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> *O:* +1 720.306.6055   *M:* *+1 (303) 396-9546*
> *Email:* jbradley at pingidentity.com
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - -
>
> *Join me at Cloud Identity Summit
> *www.cloudidentitysummit.com
> Twitter: @CloudIDSummit <http://twitter.com/#!/@CloudIDSummit>
> Facebook.com/CloudIdentitySummit <http://facebook.com/CloudIdentitySummit>
>
> *   Connect with me*
>    Twitter:  <https://twitter.com/ve7jtb>@<http://twitter.com/#!/@user_name>
> ve7jtb
>    LinkedIn.com/in/v7jtb <http://linkedin.com/in/ve7jtb>
>
>
>
>
>
>
>
>
>
>
> On 2013-06-03, at 1:19 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>
> 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. ****
> ** **
> 1) MUST****
> 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>****
> 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****
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -****
> *O:* +1 720.306.6055   *M:* *+1 (303) 396-9546*****
> *Email:* jbradley at pingidentity.com****
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - -  - - - - - - - - - -
> ****
>
> *Join me at Cloud Identity Summit
> *www.cloudidentitysummit.com
> Twitter: @CloudIDSummit <http://twitter.com/#!/@CloudIDSummit>
> Facebook.com/CloudIdentitySummit <http://facebook.com/CloudIdentitySummit>
> ****
>
> *   Connect with me*
>    Twitter: @ <http://twitter.com/#!/@user_name>ve7jtb
>    LinkedIn.com/in/v7jtb <http://linkedin.com/in/ve7jtb>****
>
> ** **
> ** **
> ** **
> ** **
> ** **
>
> ** **
> ** **
> On 2013-06-02, at 11:36 PM, Mike Jones <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, per
> http://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] *On Behalf Of *Nat Sakimura
> *Sent:* Sunday, June 02, 2013 2:31 PM
> *To:* Bradley John; 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? ****
>
> =nat ****
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab****
> ** **
>
>
> ****
> ** **
> --
> Nat Sakimura (=nat)****
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130604/b9e3eeb6/attachment-0001.html>


More information about the Openid-specs-ab mailing list