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

Nat Sakimura sakimura at gmail.com
Thu Sep 4 03:10:02 UTC 2014


Actually, it does not matter at this point whether XRI providers will
become OpenID Connect Providers.
A user can set his preferred issuer there without any XRI provider
intervention.
It would be nice if XRI provider would support OpenID Connect and make a
default binding for (+openid_iss),
but it is a NTH.


2014-09-04 11:54 GMT+09:00 Nat Sakimura <sakimura at gmail.com>:

> OK. Will try.
>
>
> 2014-09-04 1:53 GMT+09:00 Mike Jones <Michael.Jones at microsoft.com>:
>
>   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 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>:
>>
>> 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> 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>
>> >> To: Mike Jones <Michael.Jones at microsoft.com>, Markus Sabadello
>> >>      <markus.sabadello at gmail.com>
>> >> Cc: "openid-specs-ab at lists.openid.net"
>> >>      <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>
>> >> 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 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 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 doing
>> something.
>> >> Thoughts?
>> >> Nat
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>



-- 
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/20140904/1d8e7b46/attachment-0001.html>


More information about the Openid-specs-ab mailing list