[Openid-specs-ab] Some comments on OpenID 2.0 to OpenID Connect Migration spec

Fri Aug 29 14:38:38 UTC 2014

Now tracking it as https://bitbucket.org/openid/connect/issue/955/

Will discuss this in twenty minutes.

2014-08-28 13:27 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com>:

> I thought there was some plan to relaunch as cloud names.   Perhaps they
> are separate.  I expect Markus knows
>
> Sent from my iPhone
>
> On Aug 27, 2014, at 11:24 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:
>
>  2 are advertised at xri.org
>   ------------------------------
> From: Nat Sakimura <sakimura at gmail.com>
> Sent: ‎8/‎27/‎2014 7:21 PM
> To: John Bradley <ve7jtb at ve7jtb.com>
> Cc: Edmund Jay <ejay at mgi1.com>; Mike Jones <Michael.Jones at microsoft.com>; Markus
> Sabadello <markus.sabadello at gmail.com>; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID
> Connect Migration spec
>
>  So, how many I-Brokers are there now?
>
> =nat via iPhone
>
> Aug 28, 2014 10:20、John Bradley <ve7jtb at ve7jtb.com> のメッセージ:
>
>   In principal that is what we created the JRD for in the XRI WG.
>
>  The question is more what NuStar is doing with the transition to cloud
> names and what roll Connect will have for whatever replaces iBrokers.
>
> Sent from my iPhone
>
> On Aug 27, 2014, at 6:38 PM, Edmund Jay <ejay at mgi1.com> wrote:
>
>   Shouldn't iss and sub contain values from the OpenID Connect provider?
> Unless, of course the OpenID Connect provider is https://xri.net
>
>  XRI resolution returns the OpenID 2.0 provider that is configured by the
> i-name owner.
>
>  So in regards to the spec, we need to determine whether it's possible to
> get the OpenID Connect iss from a GET request to https://xri.net/(some i-name)
> with an Accept header of application/json.
>
>  If not, then we need to think of another scheme for verification of XRI
> OpenID 2.0 Identifiers.
>
>
>
>   ------------------------------
> *From:* Mike Jones <Michael.Jones at microsoft.com>
> *To:* Markus Sabadello <markus.sabadello at gmail.com>; Nat Sakimura <
> sakimura at gmail.com>
> *Cc:* "openid-specs-ab at lists.openid.net" <openid-specs-ab at lists.openid.net>
>
> *Sent:* Wednesday, August 27, 2014 12:18 PM
> *Subject:* Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID
> Connect Migration spec
>
>   I suspect that the “iss” would be https://xri.net and the “sub” would
> be the i-number, such as “*=!91F2.8153.F600.AE24*”.
>
> I guess the real question we haven’t explicitly asked is whether xri.net
> can/will become an OpenID Connect provider – which is what would make
> migration possible.  What are your thoughts on this, Markus?
>
>                                                             -- Mike
>
>
>
>  *From:* Markus Sabadello [mailto:markus.sabadello at gmail.com
> <markus.sabadello at gmail.com>]
> *Sent:* Wednesday, August 27, 2014 11:50 AM
> *To:* Nat Sakimura
> *Cc:* Mike Jones; openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID
> Connect Migration spec
>
>   Yes to me it feels right to just say that openid2_id is the OpenID 2.0
> Claimed Identifier.
>  What I don't fully understand yet is whether in the OIDC world the
> Authorization Endpoint would be hosted 1. at https://xri.net/some/path,
> or 2. individually by the i-brokers.
>  If 1., then for the migration spec I think no discovery step would be
> needed, since the issuer would always be https://xri.net anyway, no?
>  What would the "iss" and "sub" fields be for an ID token issued for an
> XRI?
>
> Markus
>
>  On Mon, Aug 25, 2014 at 6:25 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>  Having said that, it is probably better to have the canonical XRI itself
> in the openid2_id.
>  Note though, Canonical ID only exists for XRI. In all other cases, it is
> the Verified Claimed ID.
>  In XRI's case, the value of the Canonical ID is used as the verified
> Claimed Identifier.
>  So, in general, just stating that openid2_id is OpenID 2.0 Identifier
> suffices.
>
>  We would however have to add text to the discovery portion.
>
>  In http(s) case, there is no change.
>  For XRI case, it has to be prefixed by https://xri.net/.
>
>  My question to Markus at this point is how realistic that xri.net will
> implement this feature.
>  Do you have any idea?
>
>  Nat
>
>  2014-08-26 0:31 GMT+09:00 Nat Sakimura <sakimura at gmail.com>:
>
>
>  That would actually complicate 90% of the cases where openid2_id is a
> http(s) URI.
>  And I probably was a bit sleepy when I wrote the last response.
>  It is not xri://xri.net/ obviously.
>  I meant https://xri.net/ etc. so that the discovery process would be
> uniform to the RPs.
>
>  2014-08-25 23:44 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com>:
>
>
>  I prefer the alternative that Markus is suggesting, in which we always
> use the OpenID 2.0 canonical identifier as the openid2_id claim value.  In
> fact, I would consider adding his example, in which this claim value is
> shown:
> "openid2_id": "*=!91F2.8153.F600.AE24*"
>
> We should then describe how to prefix this value to perform discovery,
> rather than removing the prefix.
>
>                                                             -- 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:* Monday, August 25, 2014 7:26 AM
> *To:* Markus Sabadello
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Some comments on OpenID 2.0 to OpenID
> Connect Migration spec
>
>  Thanks Markus,
>
>  I created tickets based on these comments.
>
>  This particular one is:
> https://bitbucket.org/openid/connect/issue/950/migration-te-4-xri-portion-needs-change-by
>
>  For the relying party, I think it would be relatively straight forward
> to strip xri:// from openid2_id if they stored XRI as pure CanonicalID and
> causes less confusion than trying to figure out the type of openid2_id by
> sniffing if it starts from "=" or "!" or "@" etc.
>
>  This comment thus seem to imply that we should add some text in section
> 7, e.g., adding:
>
>  If the OpenID 2.0 Identifier starts with xri://xri.net/ then the relying
> party MUST extract the Canonical XRI by stripping "xri://xri.net/" from
> the beginning of the OpenID 2.0 Identifier.
>
>  What do you think?
>
>  Nat
>
>  2014-08-23 21:36 GMT+09:00 Markus Sabadello <markus.sabadello at gmail.com>:
>  In section 4:
> "For XRI, OpenID 2.0 Identifier MUST be created as https://xri.net/
> concatenated with the user’s verified XRI without the xri:// scheme. "
> The problem with this I think is that in OpenID 2.0, for an XRI the
> Claimed Identifier is the pure CanonicalID (I-Number), without https://
> or xri:// scheme. For example, an RP might have *=!91F2.8153.F600.AE24*
> as the Claimed Identifier (openid2_id) for a user in its database.
> So I think in section 4, we should either not say anything specific at all
> about XRI, or say something like this:
>
> "For XRI, OpenID 2.0 Identifier MUST be the content of the <CanonicalID>
> element, as specified in [OpenID.2.0]"
>  Then an example ID Token would be:
>
> {
>
>  "iss": "?? not sure",
>
>  "sub": "?? not sure",
>
>  "aud": "s6BhdRkqt3",
>
>  "nonce": "n-0S6_WzA2Mj",
>
>  "exp": 1311281970,
>
>  "iat": 1311280970,
>
>  "openid2_id": "*=!91F2.8153.F600.AE24*"
>
> }
>
> But then I can see that obtaining an "iss" as described in sections 2 and
> 6 won't work.
>
>
>
>
>  --
> Nat Sakimura (=nat)
>  Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
>
>  --
> Nat Sakimura (=nat)
>  Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
>
>  --
> 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
>
>
>     _______________________________________________
> 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/20140829/c79575c5/attachment.html>