[OpenID] [rest-discuss] unrestful OpenId attribute exchange draft ?

[Story Henry]

Thanks for the feedback Norman.  I am forwarding this back to the  
openid group, because your responses have really helped me understand  
the issues better.

By the way there is a really useful pdf book on OpenId that is  
available for review currently, before it goes to the printer:

http://www.openidbook.com

On 26 Jul 2007, at 18:26, Norman Gray wrote:

> Henry, hello.
>
> On 26 Jul 2007, at 15:32, Henry Story wrote:
>
>> (2) It does not feel RESTful. If something is to return information
>> it should have a URL. Here there is very clearly overlapping of
>> concerns as explained above. What is the url for information for one
>> identity here? I have a large alarm bell ringing when I read sections
>> such as: "Fetch message" and "store message". Is that not the
>> equivalent of HTTP GET and PUT?
>
>>     -b- query language: SPARQL though not yet finished does
>> everything that is needed here as shown in the example given at [1]
>
> Disclaimer: I've looked through the attribute exchange draft, but  
> haven't studied it; the following is not, I think, dependent on the  
> fine details.

Neither had I. Chapter 6 of the book I mentioned above goes over it  
in easier language.

> My feeling is that SPARQL is not a good fit here, because this  
> might be a case where a RESTful approach is not ideal.
>
> Attribute exchange is pretty fundamentally a conversation: if I  
> want to get a set of Ignatius's attributes from you, I have to  
> assure myself of who you are, but you also have to either (a)  
> assure yourself of who I am, and that I am permitted to get all of  
> Ignatius's attributes, or (b) I have some other legitimate need to  
> get this information, which fits in with a pre-existing policy:
>
>   me: tell me Ignatius's age
>   you: why do you want to know?
>   me: I'll only sell him drink if he's over 18
>   you: OK: he's over 18, but I'm not telling you his birthday
>   me: that'll do

Hehe. That would indeed be very cool. One could I am sure do that in  
SPARQL too, but one would need a relation such as  
query:IWillAnswerOnlyIfYouAnswerThisFirst relation.


> When fully general, this turns into a decidedly non-trivial problem.

Indeed... Interesting idea. But I don't think that this is what they  
are proposing... as I just realized you admit below.

> The simpler case which seems to be suggested in OpenID docs and the  
> attribute exchange draft, of allowing the (human) OpenID owner to  
> choose on the fly what attributes are released to a relying party,  
> still involves a three-way interaction, between the relying party,  
> the IdP and the human.

Ah thanks for pointing that out. I just found that stated in the book

"In general, any time a Consumer requests these additional parameters  
for user registration purpose, the identity provider should prompt  
the End User before sending these parameters to the Consumer. The End  
User should be given a choice which parameters it wants to send to  
the Identity Provider"

I had not picked up on this.

> Although you can characterise that as a GET which might take a long  
> while to be retrieved (when will the user come back from coffee?),  
> it feels a bit forced to me.  It's doable, but it's not clear how  
> `this is who I am and why I want your birthday', or even just `this  
> is who I am', would be included in the SPARQL request.
>

Well I think one could look at this as a form of indirect SELECT  
SPARQL query where the
variables in the SELECT get to be chosen by the end user. Ie the  
Consumer sends

WHERE {
    ?p foaf:openid <http://openid.sun.com/bblfish> .
   OPTIONAL { ?p foaf:birthday ?bday } .
   OPTIONAL { ?p foaf:mbox ?mbox } .
}

and the End User gets to prepend the SELECT clause

SELECT ?bday

if he only wants the birthday to be passed on but not the mbox.

It is not done as a SPARQL request because that would make for URL  
redirects that are much too long. So really the protocol is working  
with a predefined template SPARQL query, and the
field names are the names of the variables passed around without the  
'?'.

Mhh looked at this way, it seems easier to understand to me, and it  
makes more sense.

Mind you in that case it should be easy to define how to change the  
information on the server: do a PUT of some foaf there. That would  
remove the I think clearly unRESTful storage protocol. I mean clearly  
here they are reinventing HTTP response codes, with things such as  
storage success, storage failure, etc...

Another thought: if one thinks about it, this redirect to the server  
has to happen because the end user does not have a rdf database to  
query. If he did then the client could query the user directly.

> The case which you describe in your (excellent) [1] is, I think,  
> the most basic case, where all the attributes are available without  
> any policy at all, and the problem is simply how does one associate  
> Ignatius's FOAF file with his OpenID.  Now, OpenID is about keeping  
> things simple, and it might be deemed valuable to keep things  
> precisely this simple; in that case, a pointer to a FOAF file would  
> indeed be hugely simpler than a new protocol.
>
>> [1] http://blogs.sun.com/bblfish/entry/foaf_openid
>

:-) ok happy to have contributed something.

I had tried to deal with the problem by having the foaf file return  
more or less information. I would have required the end user specify  
what should be visible for that Client when entering his password.  
There was some hand-waving there, because it was not so clear how one  
can identify the server. One would have to:

   - give the client an OpenId too, which I was thinking could be  
linked to the server_root
   - identify the foaf file somehow as being identity dependent,  
perhaps by adding a new HTTP header pointing to the login point, so  
that the client would know to login for more information
   - and of course the foaf file would have to be served by the same  
service as the openid authentication.

But that may in the end be more complicated than the query part of  
the protocol defined above, and does not feel as clean as the  
indirect query idea.

It looks like the idea of querying the end user directly would be the  
best, once he has been correctly identified. In that case though the  
end user is not that different from a very slow web server.

It would be interesting to think more about a SPARQL based service,  
given the flexibility such a language and format make available.

> Separately:
>
>> PS.  Now criticism (1) above is a little tricky perhaps because if
>> the Identity Provider has no say
>> over the OpenId resource, and that is used to point to personal
>> information, then the open id could be describing itself in ways that
>> would be completely unacceptable to the organisation controlling the
>> Identity Provider. So there may be a good reason to have it have some
>> control over the OpenId, or  for one to want to ask it questions
>> regarding the identity of the person associated with that id.
>>
>> In my view what will happen is that in the end all identity providers
>> will have control of their openid they give out. So as Sun gives out
>> http://openid.sun.com/bblfish so visa will give out
>> http://visa.com/iod/1231341 and there will then be my personal openid
>> foaf file, which will link them all together (if I want to).
>
> Can you elaborate on this?  Do you just mean that sun.com might not  
> want openid.sun.com/bblfish to be able to say 'My politics are X'?

No but I suppose they might not want it to say  "My name is Jonathan  
Schwartz" :-)

> My first reaction to such a prohibition would be that it  
> misunderstands what (I think) OpenID is clever about.  OpenID  
> avoids some of X.509's problems by _not_ making any link between  
> online and offline entities.  So, pace Tim Bray in [a], all an  
> OpenID says is that its owner is the same person over time; the IdP  
> doesn't warrant that the name means anything.  The IdP doesn't even  
> warrant that the attributes it's supplying are true, simply that  
> these are honestly what the offline human told it to say.

That is a good response. And so having the OpenId be a FoafDocument,  
or point to a FoafDocument that is outside of the sphere of influence  
of the Identity Provider is ok. As OpenId is specified currently.

But!

Sun stated that all OpenIds starting with http://blogs.sun.com/ 
bblfish identify Sun employees. They have had to do that verbally  
since OpenId by itself does not make any tools available to make this  
possible.

Now in my last post I showed how Sun could make this statement with a  
few simple additional foaf relations [2], and by creating itself a  
corporate foaf file. Essentially you can think of the Identity  
Provider service as a group identifier, that can also identify the  
members of the group.  This would then give a mechanical way for sun  
to make a statement about that service. The service could also make  
the same point by pointing back in a rdf/xml representation back to  
the Sun Microsystems foaf file.

In that situation it is clear that Sun will not want the attributes  
on its service endpoint to be all equally updatable, because they are  
now making claims about the members of the Sun group, with legal  
responsibilities. Neither would Sun want the foaf file linked to from  
the openid.sun.com/bblfish to be completely in the hands of the  
employee. Some attributes may, but others may not.

So I think I have shown in [2] that OpenId could be used for a lot  
more than what it is used for currently, with a little bit of extra  
metadata, which is neat.


> Or am I missing your point?
>
> Best wishes,
>
> Norman
>
> [a] http://www.tbray.org/ongoing/When/200x/2007/02/24/OpenID#p-3
>

[2] http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun


> -- 
> ------------------------------------------------------------
> Norman Gray  :  http://nxg.me.uk
> eurovotech.org  :  University of Leicester, UK
>
>