So, what is an OpenID Extension?

Nat Sakimura sakimura at gmail.com
Thu Aug 13 22:20:14 UTC 2009


OK. So I take it as the current sentiment of the specs community that by
doing so would not kick out CX from the OpenID Extension qualification out
of box.
=nat

On Fri, Aug 14, 2009 at 5:46 AM, David Recordon <david at sixapart.com> wrote:

> I think you should use CX as the "proving grounds" to see what it might end
> up looking like.
> --David
>
> On Aug 13, 2009, at 10:41 AM, Nat Sakimura wrote:
>
> Ah, I was having agony there.
> My current draft actually have artifact in it, then I started to wonder
> "would it be OpenID Extension? It does not entirely piggyback on auth
> request and response..."
>
> So I started a thread here, and that the response so far was that it will
> not be an OpenID Extension, and for artifact to be able to be done, we have
> to rev up the OpenID Auth to include the artifact.
>
> If it is not the case, I am more than happy.
>
> =nat
>
> On Fri, Aug 14, 2009 at 2:28 AM, David Recordon <david at sixapart.com>wrote:
>
>> Don't you already have the CX working group?  Why not experiment there?
>> --David
>>
>> On Aug 13, 2009, at 10:24 AM, Nat Sakimura wrote:
>>
>> OK. Then, let us start it. What would be the process?
>> Starting WG takes at least 6 weeks and holding the discussion back for the
>> period does not make much sense.
>>
>> =nat
>>
>> On Fri, Aug 14, 2009 at 2:05 AM, David Recordon <david at sixapart.com>wrote:
>>
>>> I think that it is more of a description of the current state, though if
>>> changed it blurs the difference between OpenID and OAuth even more.  It's
>>> worth trying out though.
>>> --David
>>>
>>> On Aug 13, 2009, at 9:05 AM, Nat Sakimura wrote:
>>>
>>> Is this "indirectness" a philosophy or just a description of the current
>>> state?  It is not only me who wants to do artifact binding, and it is
>>> much simpler than doing both OpenID and OAuth.
>>>
>>> =nat
>>>
>>> On Fri, Aug 14, 2009 at 12:39 AM, Andrew Arnott <andrewarnott at gmail.com>wrote:
>>>
>>>> OpenID extensions must be carried by indirect messages (through the
>>>> browser).  If you're looking for ways for server-to-server communication to
>>>> get attributes, I suggest you look at OAuth.  Specifically perhaps the
>>>> OpenID+OAuth extension, which could enable the RP to send the request
>>>> directly to the OP for these large payloads you're talking about.
>>>> --
>>>> Andrew Arnott
>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>> death your right to say it." - S. G. Tallentyre
>>>>
>>>>
>>>> On Thu, Aug 13, 2009 at 8:03 AM, Nat Sakimura <sakimura at gmail.com>wrote:
>>>>
>>>>>  Hmmm. So, there is no way we can do direct communication in an
>>>>> extension? What I want to do is to send the large payload directly
>>>>> between the servers and move only the reference through OpenID Authn request
>>>>> and response so that
>>>>>
>>>>> 1) mobile clients will not choke.
>>>>> 2) is going to be more secure.
>>>>>
>>>>> In AX, there is a notion of update_url, but is that also used only for
>>>>> indirect communication through browser?
>>>>>
>>>>> I feel that it is extremely limiting if we cannot do the server to
>>>>> server communication.
>>>>>
>>>>> If that is not a possibility, then I should probably do the server to
>>>>> server portion elsewhere, and just do the reference/artifact moving through
>>>>> OpenID AuthN, but that sounds like OpenID strangling itself.
>>>>>
>>>>> =nat
>>>>>
>>>>> On Thu, Aug 13, 2009 at 11:01 PM, James Henstridge <james at jamesh.id.au
>>>>> > wrote:
>>>>>
>>>>>> On Thu, Aug 13, 2009 at 8:05 AM, Nat Sakimura<sakimura at gmail.com>
>>>>>> wrote:
>>>>>> > I blogged bout the subject here:
>>>>>> > http://www.sakimura.org/en/modules/wordpress/index.php?p=91
>>>>>> >
>>>>>> > What would be the consensus here?
>>>>>>
>>>>>> My reading of the spec (and what I believe is the author's intent) is
>>>>>> that OpenID extensions do indeed piggyback on an authentication
>>>>>> request.  The note about including the extension's type URI in XRDS is
>>>>>> a way that an OpenID provider can advertise support for the extension.
>>>>>>
>>>>>> Note that in OpenID 2.0, sending openid.identifier in an
>>>>>> authentication request is optional.  So you could potentially use an
>>>>>> extension without actually authenticating as a particular user.  From
>>>>>> section 9.1:
>>>>>>
>>>>>> """
>>>>>> "openid.claimed_id" and "openid.identity" SHALL be either both present
>>>>>> or both absent. If neither value is present, the assertion is not
>>>>>> about an identifier, and will contain other information in its
>>>>>> payload, using extensions (Extensions).
>>>>>> """
>>>>>>
>>>>>> James.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nat Sakimura (=nat)
>>>>> http://www.sakimura.org/en/
>>>>>
>>>>> _______________________________________________
>>>>> specs mailing list
>>>>> specs at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> http://www.sakimura.org/en/
>>>  _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> http://www.sakimura.org/en/
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
>
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090814/ea0f804d/attachment.htm>


More information about the specs mailing list