<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: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;}
.MsoChpDefault
{mso-style-type:export-only;}
@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>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>
</body>
</html>