[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 04:07:03 UTC 2014


I just made a commit.

For HTML, see http://openid.bitbucket.org/openid-connect-migration-1_0.html

For XML: https://bitbucket.org/openid/connect/commits/6cf55b10e137

I also added examples so the change seems big, but the normative text added
is just two lines.


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

> 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
>



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


More information about the Openid-specs-ab mailing list