So, what is an OpenID Extension?

[Nat Sakimura]

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20090814/7a8efa3f/attachment.htm>