[OpenID] Simple Registration Extension 1.1 draft 1

[Peter Williams]

In http://blogs.sun.com/bblfish/entry/restful_semantic_web_services
Henry writes about "<#theBook> shop:addToCart <http://shop.eg/cart/> ." 

 

So imagine now that the OpenID 2.0 namespace process has formalized 

 

openid.ns.vfn=http://shop.eg/books/isbn/0596529260

 

openid.vfn=#theBook 

 

openid.vfn.#shop:addToCart = http://shop.eg/cart/

openid.vfn.#shop:addToCart.resultsetencoding = #shop:addToCart#sparqlxml

 

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. 

 

The variables bound by the query would then be returned as AX attributes
in the positive assertion (id_res).

 

The value of resultset would determine how the variables would be
encoded in the AX values. If #shop:addToCart#sparqlxml, 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.

 

 

 

 

 

 

> -----Original Message-----

> From: general-bounces at openid.net [mailto:general-bounces at openid.net]
On

> Behalf Of Jack

> Sent: Wednesday, September 12, 2007 12:01 AM

> To: general at openid.net

> Subject: Re: [OpenID] Simple Registration Extension 1.1 draft 1

> 

> Kevin Turner wrote:

> > On Tue, 2007-09-11 at 14:51 +0100, Jack wrote:

> >> ".sreg" part is going to depend on the namespace mapping that is

> >> defined by the "openid.ns.something" parameter.  And so the part

> >> called "openid.ns.sreg" _IS_ required, although it might actually

> >> be "openid.ns.something" - the other parts cannot be evaluated

> >> without the namespace declaration.

> >

> > This is dependent on the version of OpenID you are using.  Version

> > 1.x does not require openid.ns, version 2.0 requires it for all

> > extensions. See

> > http://openid.net/specs/openid-authentication-2_0-12.html#extensions

> >

> > This applies to your comments about the presence or absence of the

> > namespace field in the response message as well.

> 

> Ah - nice. So Sreg 1.1 can be used with either OpenID 1.x or OpenID

> 2.0,

> even though namespaces aren't covered by 1.x.

> 

> I suppose that means that a Sreg 1.1 extension-handler that has to
work

> with OpenID1.x MUST use the literal namespace label "openid.sreg"?

> 

> I guess it's a significant disadvantage of spec fragmentation, that
you

> risk conflicts like this:

> 

> OpenID 2.0:

>      "To associate keys and values in a message with an extension, the

>       key MUST be associated with the Type URI."

> 

> SReg 1.1:

>      "All of the following request fields are OPTIONAL, though at
least

>       one of "openid.sreg.required" or "openid.sreg.optional" MUST be

>       specified in the request.

>        openid.ns.sreg:

>            "http://openid.net/extensions/sreg/1.1"

>        [...]

> >

> > This is true, but making a distinction between the two allows for
the

> >  provider to show a UI hint.

> 

> OK, that's the only purpose that I could see in it. However I have yet

> to meet a OP that displays such a hint (or perhaps I just didn't
notice

> it).

> >

> >> Is there a requirement that the namespace label in the response

> >> should have the same value as it had in the request? That is,

> >> should an RP be prepared for the label to have changed?

> >

> > That's really the only sane way to write an OpenID 2.0 message

> > parser. The label is only meaningful in the context of that one

> > message, and it's nothing more than an alias.

> >

> Good. Now I'm wondering if I can think up a scenario that would result

> in the OP having to switch labels between the request and the
response,

> because of a collision. That would have to result from extension data

> being included in the response that wasn't asked-for in the request, I

> suppose. And as far as I can see, that is explicitly permitted - "The

> behavior in the case of missing required fields or extra, unrequested

> fields is up to the Consumer." [Sreg1.1#response_format]

> 

> OK, thanks for clarifying.

> 

> --

> Jack.

> _______________________________________________

> general mailing list

> general at openid.net

> http://openid.net/mailman/listinfo/general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070912/149f41e3/attachment-0002.htm>