<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@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:Tahoma;
panose-1:2 11 6 4 3 5 4 4 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";}
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;}
code
{mso-style-priority:99;
font-family:"Courier New";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 92.4pt 1.0in 92.4pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoPlainText>I think my suggestion builds upon what was mentioned below,
to be fair: <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> -----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>> From: general-bounces@openid.net
[mailto:general-bounces@openid.net] On<o:p></o:p></p>
<p class=MsoPlainText>> Behalf Of Recordon, David<o:p></o:p></p>
<p class=MsoPlainText>> Sent: Monday, July 30, 2007 11:05 AM<o:p></o:p></p>
<p class=MsoPlainText>> To: Story Henry; general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> Cc: foaf-dev<o:p></o:p></p>
<p class=MsoPlainText>> Subject: Re: [OpenID] openid, foaf and attribute
exchange<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> One thing to think about is that the Attribute
Exchange spec could be<o:p></o:p></p>
<p class=MsoPlainText>> used to do nothing more than move around a FOAF
file, vCard, etc as one<o:p></o:p></p>
<p class=MsoPlainText>> of the attributes.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Great feedback though.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Thanks,<o:p></o:p></p>
<p class=MsoPlainText>> --David<o:p></o:p></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoPlainText>It goes a bit further as (a) the AX attribute(s) brings
back part(s) of the FOAF file and any relationship the FOAF file has with other
remote RDF resource, (b) its not limited to FOAF and PPDs, and (c) OpenID
Extensions and AX protocol elements are acting basically as a custom OpenID
binding of the SPARQL protocol (W3C standardized #1 SOAP binding and #2 http
binding. The suggestion embodies the idea that OpenID is an additional binding:
the “henry semweb-webservice” binding. <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>It’s also a reverse binding ( in the tradition of
the POAS and ECP profile of WebSSO from OASIS) as the return_to address is the
identity gating access to the query execution.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>What is interesting with the invention is it only became possible
with OpenID 2.0 post draft #11+ (as Jack pointing out to me privately) when RP
discovery became mandatory and a security enforcing function (SEF). Given this
SEF is now critical for enforcing UCI Claims, one can leverage a sideeffect of
the authorization information implied by authenticating and discovering the return_to:
the return_to becomes an identity claim usable in all reverse binding I&A situations,
in and of itself.<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> general-bounces@openid.net
[mailto:general-bounces@openid.net] <b>On Behalf Of </b>Peter Williams<br>
<b>Sent:</b> Wednesday, September 12, 2007 8:32 AM<br>
<b>To:</b> Jack; general@openid.net<br>
<b>Subject:</b> Re: [OpenID] Simple Registration Extension 1.1 draft 1<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoPlainText>In <a
href="http://blogs.sun.com/bblfish/entry/restful_semantic_web_services">http://blogs.sun.com/bblfish/entry/restful_semantic_web_services</a>
Henry writes about "<#theBook> shop:addToCart
<http://shop.eg/cart/> ." <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>So imagine now that the OpenID 2.0 namespace process has
formalized <o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>openid.ns.vfn=<code><span
style='font-size:10.0pt'>http://shop.eg/books/isbn/0596529260</span></code><o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>openid.vfn=#theBook <o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'><o:p> </o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>openid.vfn.#shop:addToCart =
http://shop.eg/cart/<o:p></o:p></p>
<p class=MsoPlainText style='margin-left:.5in'>openid.vfn.#shop:addToCart.resultsetencoding
= #shop:addToCart#sparqlxml<o:p></o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'>What I’m thinking is that the resource at vfn would be
determined as RDF and the graphs be obtained only upon receipt of the check_id
immediate. The semantics of the shop:addToChar method would then be evaluated
from the RDF only once the RP discovery has completed, and the return_to value
is verified. Then, the sparql query associated with the method would posted
off. <o:p></o:p></span></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'>The variables bound by the query would then be returned as AX
attributes in the positive assertion (id_res).<o:p></o:p></span></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'>The value of resultset would determine how the variables would be
encoded in the AX values. If </span>#shop:addToCart#sparqlxml<span lang=EN
style='font-family:"Verdana","sans-serif";color:black'>, for example, one AX
attribute would be returned (an XML document). Other encodings could be
defined. For example, take the first record of the query results and its bound
variables (named in the query) and return the values as similarly named AX
attributes.<o:p></o:p></span></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><span lang=EN style='font-family:"Verdana","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText><o:p> </o:p></p>
<p class=MsoPlainText>> -----Original Message-----<o:p></o:p></p>
<p class=MsoPlainText>> From: general-bounces@openid.net
[mailto:general-bounces@openid.net] On<o:p></o:p></p>
<p class=MsoPlainText>> Behalf Of Jack<o:p></o:p></p>
<p class=MsoPlainText>> Sent: Wednesday, September 12, 2007 12:01 AM<o:p></o:p></p>
<p class=MsoPlainText>> To: general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> Subject: Re: [OpenID] Simple Registration Extension
1.1 draft 1<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Kevin Turner wrote:<o:p></o:p></p>
<p class=MsoPlainText>> > On Tue, 2007-09-11 at 14:51 +0100, Jack wrote:<o:p></o:p></p>
<p class=MsoPlainText>> >> ".sreg" part is going to depend on
the namespace mapping that is<o:p></o:p></p>
<p class=MsoPlainText>> >> defined by the
"openid.ns.something" parameter. And so the part<o:p></o:p></p>
<p class=MsoPlainText>> >> called "openid.ns.sreg" _IS_
required, although it might actually<o:p></o:p></p>
<p class=MsoPlainText>> >> be "openid.ns.something" - the
other parts cannot be evaluated<o:p></o:p></p>
<p class=MsoPlainText>> >> without the namespace declaration.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > This is dependent on the version of OpenID you
are using. Version<o:p></o:p></p>
<p class=MsoPlainText>> > 1.x does not require openid.ns, version 2.0
requires it for all<o:p></o:p></p>
<p class=MsoPlainText>> > extensions. See<o:p></o:p></p>
<p class=MsoPlainText>> >
http://openid.net/specs/openid-authentication-2_0-12.html#extensions<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > This applies to your comments about the
presence or absence of the<o:p></o:p></p>
<p class=MsoPlainText>> > namespace field in the response message as
well.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> Ah - nice. So Sreg 1.1 can be used with either
OpenID 1.x or OpenID<o:p></o:p></p>
<p class=MsoPlainText>> 2.0,<o:p></o:p></p>
<p class=MsoPlainText>> even though namespaces aren't covered by 1.x.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> I suppose that means that a Sreg 1.1
extension-handler that has to work<o:p></o:p></p>
<p class=MsoPlainText>> with OpenID1.x MUST use the literal namespace label
"openid.sreg"?<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> I guess it's a significant disadvantage of spec
fragmentation, that you<o:p></o:p></p>
<p class=MsoPlainText>> risk conflicts like this:<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> OpenID 2.0:<o:p></o:p></p>
<p class=MsoPlainText>> "To associate
keys and values in a message with an extension, the<o:p></o:p></p>
<p class=MsoPlainText>> key MUST be
associated with the Type URI."<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> SReg 1.1:<o:p></o:p></p>
<p class=MsoPlainText>> "All of the
following request fields are OPTIONAL, though at least<o:p></o:p></p>
<p class=MsoPlainText>> one of "openid.sreg.required"
or "openid.sreg.optional" MUST be<o:p></o:p></p>
<p class=MsoPlainText>> specified in the
request.<o:p></o:p></p>
<p class=MsoPlainText>>
openid.ns.sreg:<o:p></o:p></p>
<p class=MsoPlainText>>
"http://openid.net/extensions/sreg/1.1"<o:p></o:p></p>
<p class=MsoPlainText>> [...]<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > This is true, but making a distinction between
the two allows for the<o:p></o:p></p>
<p class=MsoPlainText>> > provider to show a UI hint.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> OK, that's the only purpose that I could see in it.
However I have yet<o:p></o:p></p>
<p class=MsoPlainText>> to meet a OP that displays such a hint (or perhaps I
just didn't notice<o:p></o:p></p>
<p class=MsoPlainText>> it).<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> >> Is there a requirement that the namespace
label in the response<o:p></o:p></p>
<p class=MsoPlainText>> >> should have the same value as it had in the
request? That is,<o:p></o:p></p>
<p class=MsoPlainText>> >> should an RP be prepared for the label to
have changed?<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> > That's really the only sane way to write an
OpenID 2.0 message<o:p></o:p></p>
<p class=MsoPlainText>> > parser. The label is only meaningful in the
context of that one<o:p></o:p></p>
<p class=MsoPlainText>> > message, and it's nothing more than an alias.<o:p></o:p></p>
<p class=MsoPlainText>> ><o:p></o:p></p>
<p class=MsoPlainText>> Good. Now I'm wondering if I can think up a scenario
that would result<o:p></o:p></p>
<p class=MsoPlainText>> in the OP having to switch labels between the
request and the response,<o:p></o:p></p>
<p class=MsoPlainText>> because of a collision. That would have to result
from extension data<o:p></o:p></p>
<p class=MsoPlainText>> being included in the response that wasn't asked-for
in the request, I<o:p></o:p></p>
<p class=MsoPlainText>> suppose. And as far as I can see, that is explicitly
permitted - "The<o:p></o:p></p>
<p class=MsoPlainText>> behavior in the case of missing required fields or
extra, unrequested<o:p></o:p></p>
<p class=MsoPlainText>> fields is up to the Consumer."
[Sreg1.1#response_format]<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> OK, thanks for clarifying.<o:p></o:p></p>
<p class=MsoPlainText>> <o:p></o:p></p>
<p class=MsoPlainText>> --<o:p></o:p></p>
<p class=MsoPlainText>> Jack.<o:p></o:p></p>
<p class=MsoPlainText>> _______________________________________________<o:p></o:p></p>
<p class=MsoPlainText>> general mailing list<o:p></o:p></p>
<p class=MsoPlainText>> general@openid.net<o:p></o:p></p>
<p class=MsoPlainText>> http://openid.net/mailman/listinfo/general<o:p></o:p></p>
</div>
</div>
</body>
</html>