No subject
Fri Feb 8 18:42:25 UTC 2008
3.1. Subject Identifier
An identifier for a set of attributes. It MUST be a URI. The subject identi=
fier corresponds to the end-user identifier in the authentication portion o=
f the messages. In other words, the subject of the identity attributes in t=
he attribute exchange part of the message is the same as the end-user in th=
e authentication part. The subject identifier is not included in the attrib=
ute exchange.=20
It seems that the only way for an RP to send an OP an OpenID message with e=
xtensions for this purpose without actually requesting authentication is to=
leave off the claimed_id and identity parameters, which kills AX's use of =
them. At least that's how I unerstand the OpenID 2.0 spec. Perhaps I misu=
nderstand it. If I do misunderstand it, how is an extension supposed to se=
nd a request without a simultaneous authentication request?
Thanks.
On Mon, May 26, 2008 at 11:43 AM, Dick Hardt <dick at sxip.com> wrote:
The Subject Identifier is to let the OP and RP know which user is being ref=
erred to. An authentication request SHOULD not be needed. =20
In other words, you should be able to do what you want to do now ... why do=
you think you can't?
-- Dick
On 25-May-08, at 7:43 AM, Andrew Arnott wrote:
Attribute Exchange seems to rely on being part of an authentication message=
as opposed to being able to work when in OpenID's no-authentication extens=
ion mode. I get this from section 3.1 of the AX spec getting the subject i=
dentifier from the authentication part of the message.
My suggestion would be that if we can, in a subsequent version of AX, allow=
AX to stand alone without OpenID having to send an authentication request =
at the same time, then given an OpenID URL by itself, people can query agai=
nst it. Now, most information would probably need to be kept private, but =
perhaps some information, like contact information, can be made available p=
rovided the requestor respond to a CAPTCHA or something like that. That wo=
uld be up to the individual OPs and their users of course as to which infor=
mation to be willing to disseminate, but the power of the feature is there.
What do you think?
--=20
Andrew Arnott _______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
--=20
Andrew Arnott
--=20
Andrew Arnott _______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general
--Apple-Mail-151--553266327
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML dir=3Dltr><HEAD></HEAD>
<BODY style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space">
<DIV id=3DidOWAReplyText13106 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I think its more=
important to fix the critical issue: follow through the intent and ensure =
the docs allow any (perhaps vendor-defined) extension (not only AX) to leve=
rage a pre-existing OpenID Association without seeking an athentication Sta=
tement (or imply the processing of authenticaiton requests signals, by an O=
P).</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>One should formalize (and correc=
t as approriate) the architecture that the OP is only one consumer of (a) a=
n attribute store (b) an Association cache. An AX responder that happens no=
t to be co-resident with the OP may leverage the association cache, fo=
r example. </FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>This implementation practice emu=
lates what goes on in the modern SSL world, where the protocol engine for i=
s distinct from the cache of sessions and associates keys. You see this don=
e nicely in WS-SX, where the ws-trust tokens pass (binary) SSL3 handshake m=
essages using XML bearers (rather than the Internet-era TLS record layer pr=
otocol) where the sessions and key stores are maintained by the WS-SX engin=
e (rather than say "load balancer stored" SSL key caches and session s=
tores, as is common in late-1990s era https). </FONT></DIV></DIV>
<DIV id=3DidSignature50680>
<DIV><FONT face=3DArial color=3D#000000 size=3D2><SPAN style=3D"FONT-SIZE: =
7.5pt"></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#000000 size=3D2><SPAN style=3D"FONT-SIZE: =
7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT>=
<BR></DIV>
<DIV>
<HR tabIndex=3D-1>
</DIV>
<DIV><FONT face=3DTahoma size=3D2><B>From:</B> Dick Hardt<BR><B>Sent:</B> M=
on 5/26/2008 12:20 PM<BR><B>To:</B> Andrew Arnott; Johnny Bufu; Josh Hoyt<B=
R><B>Cc:</B> OpenID List<BR><B>Subject:</B> Re: [OpenID] Attribute Exchange=
without simultaneous authentication<BR></FONT><BR></DIV></DIV>
<DIV>A reasonable suggestion.=20
<DIV><BR></DIV>
<DIV>Johnny, Josh?</DIV>
<DIV><BR></DIV>
<DIV><BR>
<DIV>
<DIV>On 26-May-08, at 12:15 PM, Andrew Arnott wrote:</DIV><BR class=3DApple=
-interchange-newline>
<BLOCKQUOTE type=3D"cite">I would suggest an optional parameter be added to=
AX called "ax.subject_id" or something like that, that would be used only =
when openid.claimed_id and openid.identity is not specified.<BR><BR>
<DIV class=3Dgmail_quote>On Mon, May 26, 2008 at 12:08 PM, Dick Hardt <<=
A href=3D"mailto:dick at sxip.com" target=3D_blank>dick at sxip.com</A>> wrote=
:<BR>
<BLOCKQUOTE class=3Dgmail_quote style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt=
0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV>
<BLOCKQUOTE type=3D"cite">
<DIV style=3D"MARGIN: 0px"><BR></DIV></BLOCKQUOTE>
<DIV><BR></DIV>Not requiring a simultaneous authentication was in=
tended to be possible. See the language from the OpenID 2.0 Authentica=
tion spec below that hints that things are possible without authentica=
ting the user.</DIV>
<DIV><BR></DIV>
<DIV>In practice, no one has wanted to move attributes without authenticati=
ng ... so the exact mechanics for doing it may not be represented in the sp=
ec.</DIV>
<DIV><BR></DIV>
<DIV>Suggestions?</DIV>
<DIV><BR></DIV>
<DIV>-- Dick<BR><BR>
<BLOCKQUOTE type=3D"cite">
<DIV style=3D"MARGIN: 0px"># openid.claimed_id</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"> Value: (optional) The Claimed Iden=
tifier.</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"> "openid.claimed_id" and "openid.id=
entity" SHALL be either both present or both absent. If neither value is pr=
esent, the assertion is not about an identifier, and will contain other inf=
ormation in its payload, using extensions (Extensions).</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"> It is RECOMMENDED that OPs accept =
XRI identifiers with or without the "xri://" prefix, as specified in the No=
rmalization (Normalization) section.</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"># openid.identity</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"> Value: (optional) The OP-Local Ide=
ntifier.</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"> If a different OP-Local Identifier=
is not specified, the claimed identifier MUST be used as the value for ope=
nid.identity.</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV>
<DIV style=3D"MARGIN: 0px"> Note: If this is set to the specia=
l value "<A href=3D"http://specs.openid.net/auth/2.0/identifier_select" tar=
get=3D_blank>http://specs.openid.net/auth/2.0/identifier_select</A>" then t=
he OP SHOULD choose an Identifier that belongs to the end user. This parame=
ter MAY be omitted if the request is not about an identifier (for instance =
if an extension is in use that makes the request meaningful without it; see=
openid.claimed_id above).</DIV>
<DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV></BLOCKQUOTE></DIV>
<DIV>
<DIV></DIV>
<DIV class=3DWj3C7c>
<DIV><BR></DIV>
<DIV><BR></DIV><BR>
<DIV>
<DIV>On 26-May-08, at 11:56 AM, Andrew Arnott wrote:</DIV><BR>
<BLOCKQUOTE type=3D"cite">I think a simultaneous authentication is necessar=
y because without it, the openid.claimed_id and openid.identity parameters =
will be missing, and thus no way for the OP to determine what Identifier is=
being queried for attributes. <BR><BR>From the AX spec:<BR>
<H3 style=3D"MARGIN-LEFT: 40px">3.1. Subject Identifier</H3>
<P style=3D"MARGIN-LEFT: 40px">An identifier for a set of attributes. It MU=
ST be a URI. <I>The subject identifier corresponds to the end-user identifi=
er in the authentication portion of the messages</I>. In other words, the <=
I>subject of the identity attributes in the attribute exchange part of the =
message is the same as the end-user in the authentication part. The subject=
identifier is not included in the attribute exchange</I>. </P>It seems tha=
t the only way for an RP to send an OP an OpenID message with extensions fo=
r this purpose without actually requesting authentication is to leave off t=
he claimed_id and identity parameters, which kills AX's use of them. =
At least that's how I unerstand the OpenID 2.0 spec. Perhaps I misund=
erstand it. If I do misunderstand it, how is an extension supposed to=
send a request without a simultaneous authentication request?<BR><BR>Thank=
s.<BR><BR>
<DIV class=3Dgmail_quote>On Mon, May 26, 2008 at 11:43 AM, Dick Hardt <<=
A href=3D"mailto:dick at sxip.com" target=3D_blank>dick at sxip.com</A>> wrote=
:<BR>
<BLOCKQUOTE class=3Dgmail_quote style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt=
0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>The Subject Identifier is to let the OP and RP know which user is bein=
g referred to. An authentication request SHOULD not be needed. =20
<DIV><BR></DIV>
<DIV>In other words, you should be able to do what you want to do now ... w=
hy do you think you can't?</DIV>
<DIV><BR></DIV>
<DIV>-- Dick<BR>
<DIV><BR>
<DIV>
<DIV>
<DIV></DIV>
<DIV>
<DIV>On 25-May-08, at 7:43 AM, Andrew Arnott wrote:</DIV><BR></DIV></DIV>
<BLOCKQUOTE type=3D"cite">
<DIV>
<DIV></DIV>
<DIV>Attribute Exchange seems to rely on being part of an authentication me=
ssage as opposed to being able to work when in OpenID's no-authentication e=
xtension mode. I get this from section <A href=3D"http://openid.net/s=
pecs/openid-attribute-exchange-1_0.html#identifier-definition" target=3D_bl=
ank>3.1</A> of the AX spec getting the subject identifier from the authenti=
cation part of the message.<BR><BR>My suggestion would be that if we can, i=
n a subsequent version of AX, allow AX to stand alone without OpenID having=
to send an authentication request at the same time, then given an OpenID U=
RL by itself, people can query against it. Now, most information woul=
d probably need to be kept private, but perhaps some information, like cont=
act information, can be made available provided the requestor respond to a =
CAPTCHA or something like that. That would be up to the individual OP=
s and their users of course as to which information to be willing to dissem=
inate, but the power of the feature is there.<BR><BR>What do you think?<BR =
clear=3Dall><BR>-- <BR></DIV></DIV>Andrew Arnott __________________________=
_____________________<BR>general mailing list<BR><A href=3D"mailto:general@=
openid.net" target=3D_blank>general at openid.net</A><BR><A href=3D"http://ope=
nid.net/mailman/listinfo/general" target=3D_blank>http://openid.net/mailman=
/listinfo/general</A><BR></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></BLOCKQU=
OTE></DIV><BR><BR clear=3Dall><BR>-- <BR>Andrew Arnott</BLOCKQUOTE></DIV><B=
R></DIV></DIV></DIV></BLOCKQUOTE></DIV><BR><BR clear=3Dall><BR>-- <BR>Andre=
w Arnott _______________________________________________<BR>general mailing=
list<BR><A href=3D"mailto:general at openid.net" target=3D_blank>general at open=
id.net</A><BR>http://openid.net/mailman/listinfo/general<BR></BLOCKQUOTE></=
DIV><BR></DIV></DIV></BODY></HTML>
--Apple-Mail-151--553266327--
More information about the general
mailing list