No subject
Fri Aug 15 23:49:43 UTC 2008
Fetch Message
The fetch message is used to retrieve personal identity attributes from an =
OpenID Provider.
Given I (really do!) come from way down in the class ranking, I read all t=
hat plainly ( but incorrectly).
There really is very little in the AX standard that indicates what I now un=
derstand - that the AX extension is _supposed_ to be used only as a messag=
e extension of an actual, classical, openid authN request/response run. Un=
like my state machine's assumption (for the last year), AX is NOT supposed =
to be used while merely leveraging an existing openid association between R=
P and OP, where the request's openid.cliamed_id AND openid.identity are bot=
h absent.
"openid.claimed_id" and "openid.identity" SHALL be either both present or b=
oth absent. If neither value is present, the assertion is not about an iden=
tifier, and will contain other information in its payload, using extensions=
(Extensions)<http://openid.net/specs/openid-authentication-2_0.html#extens=
ions>.
Now I know the right model (claimed_id =3D identity =3D not null where typ=
eof(identity) isa URI/XRI) , if I carefully read section3.1, I __can__ (an=
d now _do_) comprehend from the very structure of the section that the fet=
ch request (of attributes) MUST accompany an identity/authentication reque=
st. That is, unlike a SAML attribute request (which need not be associated=
with any previous run of the authentication protocol), an AX fetch req ext=
ension must only be used as an extension of a classical openid authN req. I=
t MUST not be used where identity=3Dclaimed_id=3Dnull.
I think I also understand, that an unsolicited AuthN response MUST NOT be e=
xtended with the AX response fields defined in 5.2 unless the OP is perform=
ing the update procedures described in the field "openid.ax.update_url". Th=
e async issuance by the OP of one or more fetch response messages (given th=
e receipt of an sponsoring update request, earlier) MAY or MAY NOT make an =
assertion about the claimed_id
(I still not sure on the last bit, to be truthful.)
Rather than just specify message elements, it would be much easier to under=
stand if ALL the states and ALL the procedures per state were listed! Then,=
one can just write a typical protocol state machine, rather than hoping th=
at the _assumed_ state table is complete.
To be fair, the phrasing of 3.1 (In other words...) DOES imply what Dick sa=
ys, (now I know the right answer). But, in 10 readings...I missed its signi=
ficance.
--_000_BFBC0F17A99938458360C863B716FE4639819AE3A2simmbox01rapn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
h3
{mso-style-priority:9;
mso-style-link:"Heading 3 Char";
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:13.5pt;
font-family:"Helvetica","sans-serif";
color:#333333;
font-weight:bold;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:24.0pt;
mso-margin-bottom-alt:auto;
margin-left:24.0pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.Heading3Char
{mso-style-name:"Heading 3 Char";
mso-style-priority:9;
mso-style-link:"Heading 3";
font-family:"Helvetica","sans-serif";
color:#333333;
font-weight:bold;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:425538368;
mso-list-type:hybrid;
mso-list-template-ids:-2102624182 67698703 67698713 67698715 67698703 6769=
8713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1917547871;
mso-list-template-ids:-88441664;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>From: general-bounces at openid.net
[mailto:general-bounces at openid.net] On Behalf Of Dick Hardt<o:p></o:p></spa=
n></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>Sent: Monday, December 01, 2008 4:57 PM=
<o:p></o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>To: Martin Atkins<o:p></o:p></span></b>=
</p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>Cc: general at openid.net<o:p></o:p></span=
></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>Subject: Re: [OpenID] SREG 1.x attribut=
es<o:p></o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'><o:p> </o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></b=
></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>AX works as you think it works Martin.<=
o:p></o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'><o:p> </o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>Peter's comments are confusing to me.<o=
:p></o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'><o:p> </o:p></span></b></p>
<p class=3DMsoPlainText style=3D'margin-left:.5in'><b><span style=3D'font-s=
ize:14.0pt;
font-family:"Calibri","sans-serif"'>-- Dick<o:p></o:p></span></b></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif"'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif"'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif"'>Let’s
look at the text::-<o:p></o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'>From “Overview”:<o:p></o:p></span></p>
<p><b><span lang=3DEN style=3D'font-family:"Calibri","sans-serif";color:bla=
ck'>This
service extension defines two message types for transferring attributes: fe=
tch
(see <a href=3D"http://openid.net/specs/openid-attribute-exchange-1_0.html#=
fetch"><span
style=3D'text-decoration:none'>Section 5<span style=3D'display:none'> =
(Fetch
Message)</span></span></a>) and store (see <a
href=3D"http://openid.net/specs/openid-attribute-exchange-1_0.html#store"><=
span
style=3D'text-decoration:none'>Section 6<span style=3D'display:none'> =
(Store
Message)</span></span></a>). Fetch retrieves attribute information from an
OpenID Provider, while store saves or updates attribute information on the
OpenID Provider. Both messages originate from the Relying Party and are pas=
sed
to the OpenID Provider via the user agent as per the OpenID Authentication
protocol specification. <o:p></o:p></span></b></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'>From “Section 5”:<o:p></o:p></span></p>
<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt=
:auto'><span
lang=3DEN style=3D'font-size:12.0pt;color:#333333'>Fetch Message<o:p></o:p>=
</span></p>
<p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-right:48.0pt;
mso-margin-bottom-alt:auto;margin-left:48.0pt'><b><span lang=3DEN
style=3D'font-size:12.0pt;color:black'>The fetch message is used to retriev=
e
personal identity attributes from an OpenID Provider. <o:p></o:p></span></b=
></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'>Given I (really do!) come from way down in the class ranking, =
I
read all that plainly ( but incorrectly).<o:p></o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'>There really is very little in the AX standard that indicates =
what
I now understand – that the AX extension is _<i>supposed</i>_ t=
o be
used only as a message extension of an actual, classical, openid authN requ=
est/response
run. Unlike my state machine’s assumption (for the last year), =
AX
is NOT supposed to be used while merely leveraging an existing openid assoc=
iation
between RP and OP, where the request’s openid.cliamed_id AND openid.i=
dentity
are both absent.<o:p></o:p></span></p>
<p style=3D'mso-margin-top-alt:5.0pt;margin-right:48.0pt;margin-bottom:5.0p=
t;
margin-left:84.0pt'><span lang=3DEN style=3D'font-family:"Verdana","sans-se=
rif";
color:black'>"openid.claimed_id" and "openid.identity"
SHALL be either both present or both absent. If neither value is present, t=
he
assertion is not about an identifier, and will contain other information in=
its
payload, using <a
href=3D"http://openid.net/specs/openid-authentication-2_0.html#extensions">=
<span
style=3D'text-decoration:none'>extensions<span style=3D'display:none'> (Ext=
ensions)</span></span></a>.
<o:p></o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'>Now I know the right model (claimed_id =3D identity =3D =
not null
where typeof(identity) isa URI/XRI) , if I carefully read section3.1,  =
;I __can__
(and now _<i>do</i>_) comprehend from the very structure of the secti=
on
that the fetch request (of attributes) MUST accompany an identity/aut=
hentication
request. That is, unlike a SAML attribute request (which need not be
associated with any previous run of the authentication protocol), an AX fet=
ch
req extension must only be used as an extension of a classical openid authN=
req.
It MUST not be used where identity=3Dclaimed_id=3Dnull.<o:p></o:p></span></=
p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'>I think I also understand, that an unsolicited AuthN response =
MUST
NOT be extended with the AX response fields defined in 5.2 unless the OP is
performing the update procedures described in the field ”</span><span
lang=3DEN style=3D'font-family:"Verdana","sans-serif";color:black'>openid.a=
x.update_url“.
The async issuance by the OP of one or more fetch response messages (given =
the receipt
of an sponsoring update request, earlier) MAY or MAY NOT make an assertion =
about
the claimed_id <o:p></o:p></span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'>(I still not sure on the last bit, to be truthful.)<o:p></o:p>=
</span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'>Rather than just specify message elements, it would be much ea=
sier
to understand if ALL the states and ALL the procedures per state were liste=
d!
Then, one can just write a typical protocol state machine, rather than hopi=
ng that
the _<i>assumed</i>_ state table is complete.<o:p></o:p></span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'><o:p> </o:p></span></p>
<p class=3DMsoPlainText><span lang=3DEN style=3D'font-family:"Verdana","san=
s-serif";
color:black'>To be fair, the phrasing of 3.1 (In other words…) DOES i=
mply
what Dick says, (now I know the right answer). But, in 10 readings…I
missed its significance.<o:p></o:p></span></p>
<p class=3DMsoPlainText><span style=3D'font-size:12.0pt;font-family:"Calibr=
i","sans-serif";
color:black'><o:p> </o:p></span></p>
</div>
</body>
</html>
--_000_BFBC0F17A99938458360C863B716FE4639819AE3A2simmbox01rapn_--
More information about the general
mailing list