[Openid-specs-ab] Ad-hoc conversation about i-names and OpenID Connect Migration 29-Aug-14

Mike Jones Michael.Jones at microsoft.com
Wed Sep 3 16:53:27 UTC 2014


Can all this be put into the draft by tomorrow morning’s call (in the Americas) so it can be reviewed then?  I think that a note should be included that it’s not clear whether any XRI providers will become OpenID Connect Providers yet or not.

                                                            -- 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: Wednesday, September 03, 2014 8:55 AM
To: John Bradley
Cc: Michael Schwartz; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Ad-hoc conversation about i-names and OpenID Connect Migration 29-Aug-14

Good point about my solution is that it is completely independent of whatever the XRI providers does, unless they shut down the forwarding service.

As long as the forwarding service is supported, I can specify https://accounts.google.com as (+openid_iss) and I am done if google allows external canonical ID to be mapped to its OpenID Connect ID. Of course, I can set up id.sakimura.org<http://id.sakimura.org> and point (+openid_iss) to it as well.
If Fullxri decides to support OpenID Connect, then he can create a default map for (+openid_iss) to its users.
Fullxri can make an independent decision on it. This kind of "distributed governance" in fact is very much in-line with the original concept of user centricity :-)

That's the beauty of this solution.

Nat

2014-09-04 0:13 GMT+09:00 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>:
Markus indicated that Respect Networks is not planning on doing Connect.

I don't think we have had input from them directly at this point.

John B.

On Sep 3, 2014, at 9:46 AM, Michael Schwartz <mike at gluu.org<mailto:mike at gluu.org>> wrote:

> Nat,
>
> If Markus is ok with the changes, then I'm ok with it. Does it align with XRI as currently conceived by Respect Networks?
>
> - Mike
>
>
>
> -------------------------------------
> Michael Schwartz
> CEO Gluu
>
>
>> Message: 2
>> Date: Wed, 3 Sep 2014 12:39:23 +0900
>> From: Nat Sakimura <n-sakimura at nri.co.jp<mailto:n-sakimura at nri.co.jp>>
>> To: Mike Jones <Michael.Jones at microsoft.com<mailto:Michael.Jones at microsoft.com>>, Markus Sabadello
>>      <markus.sabadello at gmail.com<mailto:markus.sabadello at gmail.com>>
>> Cc: "openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>"
>>      <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
>> Subject: Re: [Openid-specs-ab] Ad-hoc conversation about i-names and
>>      OpenID Connect Migration 29-Aug-14
>> Message-ID: <20140903123923.24425e3f1a08a945e78af87a at nri.co.jp<mailto:20140903123923.24425e3f1a08a945e78af87a at nri.co.jp>>
>> Content-Type: text/plain; charset=US-ASCII
>> For what is worth,unlike I had hoped for, XRI would need a special casing.
>> Also, whether xri.net<http://xri.net> would support this spec is unclear.
>> Best compromise that I can think of right now is to use the forwarding
>> service of XRI.
>> Forwarding service is a service that XRI providers needs to implement.
>> You can create a node under your XRI to point to another location.
>> For example, I can define
>> =nat/(+contact)
>> to forward it to a contact page of my choice.
>> Similarly, I could create
>> =nat/(+openid_iss)
>> and map it to any page.
>> For example, if my OpenID Connect issuer is https://example.com/
>> then I can define =nat/(+openid_iss) to map to https://example.com/.
>> It works this way.
>> 1) The client sends request to https://xri.net/=nat/(+openid_iss).
>> 2) The host xri.net<http://xri.net> responds with 302 redirect to for example,
>>    http://forwarding.fullxri.com/forwading/=nat/(+openid_iss)
>> 3) The client send request to it.
>> 4) The host replies with 302 redirect to
>>   https://example.com/
>> 5) The client requests https://example.com/.
>> 6) The page returns 200 OK so the redirection sequence terminates here.
>> 7) Now the client has found that https://example.com/ is the
>>   authoritative OpenID Connect issuer.
>> 8) Match it to the value of "iss" in the ID Token.
>> This should work with any XRI provider without xri.net<http://xri.net> doing something.
>> Thoughts?
>> Nat
> _______________________________________________
> 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



--
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/20140903/f76d2f9c/attachment.html>


More information about the Openid-specs-ab mailing list