|
So, what is an OpenID Extension?
|
|
Re: So, what is an OpenID Extension?
On Thu, Aug 13, 2009 at 8:05 AM, Nat Sakimura< sakimura@...> 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.
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
Yes, in OpenID 2.0 the identifiers are optional so an extension could
provide all the functionality. Eg . Attribute Exchange could be used
to move attributes without authenticating.
-- Dick
On 2009-08-13, at 7:34 AM, "James Henstridge" < james@...>
wrote:
> On Thu, Aug 13, 2009 at 8:05 AM, Nat Sakimura< sakimura@...>
> 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.
> _______________________________________________
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs>
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
I'll just add that it turns out there are interesting scenarios for extensions w/o openid.identity, such as verifying membership in an organization by asking a trusted OP for an attribute via AX.
-- 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 7:01 AM, James Henstridge <james@...> wrote:
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.
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> wrote:
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@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
Hey Dick,
Any prospect of getting IPR permission so that you can join the WGs here? We are waiting for you!
=nat On Thu, Aug 13, 2009 at 11:43 PM, Dick Hardt <Dick.Hardt@...> wrote:
Yes, in OpenID 2.0 the identifiers are optional so an extension could
provide all the functionality. Eg . Attribute Exchange could be used
to move attributes without authenticating.
-- Dick
On 2009-08-13, at 7:34 AM, "James Henstridge" <james@...>
wrote:
> On Thu, Aug 13, 2009 at 8:05 AM, Nat Sakimura< sakimura@...>
> 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.
> specs mailing list
> specs@...
> http://lists.openid.net/mailman/listinfo/openid-specs
>
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
RE: So, what is an OpenID Extension?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
In AX you can define any attribute you want. The attribute could be a URL that enables one site to request the data directly.
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@...> wrote:
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@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
That requesting data portion cannot be in OpenID Extension, or can it?
Please have a look at http://docs.google.com/View?id=dhsz4ffx_84g7wr99g3 that I am working on right now for CX, especially the section 4. It probably is a stretch, but I believe is sensible. It is using AX in both direct and indirect communication. Direct communication portion is not quite compliant to the AX spec., but I am trying to reuse as much as I can.
=nat
On Fri, Aug 14, 2009 at 12:04 AM, Dick Hardt <Dick.Hardt@...> wrote:
In AX you can define any attribute you want. The attribute could be a URL that enables one site to request the data directly.
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@...> wrote:
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/
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> wrote:
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)
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> wrote:
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)
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> wrote: 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)
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> 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@...> wrote:
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) -- Nat Sakimura (=nat) http://www.sakimura.org/en/
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> 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@...> wrote: 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) -- Nat Sakimura (=nat) http://www.sakimura.org/en/
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
-- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> 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@...> 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@...> wrote:
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) -- Nat Sakimura (=nat) http://www.sakimura.org/en/
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> 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@...> 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@...> wrote: 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) -- Nat Sakimura (=nat) http://www.sakimura.org/en/
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
-- Nat Sakimura (=nat) http://www.sakimura.org/en/
-- Nat Sakimura (=nat) http://www.sakimura.org/en/ _______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
|
Re: So, what is an OpenID Extension?
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@...> 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@...> 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@...> 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@...> 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@...> 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@...> wrote:
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) -- Nat Sakimura (=nat) http://www.sakimura.org/en/
specs mailing list
specs@...
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/
_______________________________________________
specs mailing list
specs@...
http://lists.openid.net/mailman/listinfo/openid-specs
|
