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

John Bradley ve7jtb at ve7jtb.com
Wed Aug 27 21:00:58 UTC 2014


An issuer only has one authorization endpoint.  xri.net would have to proxy all the authentication. 

OpenID connect is not designed to validate XRI identifiers.    They could be used for discovery in the same way email addresses are. 

Sent from my iPhone

> On Aug 27, 2014, at 3:18 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> 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] 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140827/90dc34de/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2734 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140827/90dc34de/attachment-0001.p7s>


More information about the Openid-specs-ab mailing list