[OpenID] Simple Registration Extension 1.1 draft 1

Wed Sep 12 17:54:05 UTC 2007

I think my suggestion builds upon what was mentioned below, to be fair: 

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

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

> Behalf Of Recordon, David

> Sent: Monday, July 30, 2007 11:05 AM

> To: Story Henry; general at openid.net

> Cc: foaf-dev

> Subject: Re: [OpenID] openid, foaf and attribute exchange

> 

> One thing to think about is that the Attribute Exchange spec could be

> used to do nothing more than move around a FOAF file, vCard, etc as
one

> of the attributes.

> 

> Great feedback though.

> 

> Thanks,

> --David

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. 

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.

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.

From: general-bounces at openid.net [mailto:general-bounces at openid.net] On
Behalf Of Peter Williams
Sent: Wednesday, September 12, 2007 8:32 AM
To: Jack; general at openid.net
Subject: Re: [OpenID] Simple Registration Extension 1.1 draft 1

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/bbf01731/attachment-0002.htm>