[OpenID] Windows Live ID OpenID CTP Status Update (August 2009)

Story Henry henry.story at bblfish.net
Sun Aug 30 19:20:01 UTC 2009 

On 30 Aug 2009, at 19:32, Peter Williams wrote:

> So that was useful.
>
> Webid are direct identifiers

Yes.

> Openid are indirect identifiers.

the http:// ones yes.
They indirectly identify the user via the foaf:openid relation.

A|--------8<-----------------------8<------------------
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix : <http://bblfish.net/people/henry/card#> .

:me foaf:openid <http://bblfish.net/> .
----------->8----------------------->8------------------

Imagine an arrow pointing from me to that web page. The foaf:openid  
relation is defined as being inverse functional, ie the inverse of  
that relation, let's call it xxx:isOpenidOf relates the web page to me  
is functional

B|---------8<-----------------------8<-------------------
<http://bblfish.net> xxx:isOpenidOf :me .
----------->8----------------------->8-------------------

so now imagine an arrow from that web page to me. I can have a number  
of different names.
Indeed another URL for me is

C|---------8<-----------------------8<-------------------
@prefix sun: <http://sixiron.sfbay.sun.com:8080/FoafServer/services/people/155492# 
 > .

sun:HS a foaf:Person;
        foaf:openid <http://bblfish.net> .
----------->8----------------------->8-------------------


from A and C an inferencing engine can deduce that

sun:HS = :me .

ie those two names refer to the same thing.

> And, from openid doctrine, the HXRI/XRI variety of openids are  
> abstract identifiers.

HXRIs are I think direct identifiers too. The protocol and the URI is  
not nearly as well established as http urls, so I have not spent a lot  
of time looking at them. But from what I understood they should be  
direct identifiers. =bblfish should identify me.

But that's ok. Because the foaf:openid relation is the one that is  
inverse functional. So HXRIs will have an inverse functional  
foaf:openid relation to the thing they identify, namely to themselves.  
Ie it should be possible to write

=bblfish foaf:openid =bblfish .

> The average vb programmer can get that set of distinctions. I don't,  
> but it already sounds like something I could easily study to get  
> over my ignorance.

A very good introductory book is "Semantic Web for the Working  
Ontologist". It's a bit of a mouthful, but it starts simple and easy  
and progresses without ever bothering about rdf/xml.

http://blogs.sun.com/bblfish/entry/semantic_web_for_the_working

> So what is an unauthoritative ssl client cert, when asserted to the  
> RP's SSL server? :-)

I suppose by "unauthoritative" you mean a client cert that is self  
signed, or where we don't care about the signature.

A certificate is a document relating an identity to a public key. The  
semantics of one of my certs would be given by:

D|--------8<-----------------------8<------------------
@prefix cert: <http://www.w3.org/ns/auth/cert#> .
@prefix rsa: <http://www.w3.org/ns/auth/rsa#> .

<> a foaf:Document;
    foaf:primaryTopic :me .

:me a foaf:Agent;
     foaf:name "Henry Story".

[] a rsa:RSAPublicKey;
    cert:identity :me;
    rsa:public_exponent [ cert:decimal "65537"] ;
    rsa:modulus [ cert:hex  
"862d6e0b8c3252a79d6eb82966f14e495c839ec2d57983ec39bfac79f8a99f887a
3ca559cfee438e90f73da143cefc0a849509d8d91e7093a94c1a39863a5bed78a0f0234a372f12dce0a9535b14d92d56827b3791352b5817681ad7949aa7831911d51827a57e46bad9190d73a69ce56ada74a59ddc0df2a7a31247bbd67445 
"] .
----------->8----------------------->8-------------------

In foaf+ssl we use the alternativate name url to name the subject of  
the certificate. If Distinguished Names were URIs we could use those  
too.

So a certificate is not a URI. It is a document sent to the server. A  
statement of identity. The rsa:RSAPublicKey node is not named - it  
does not have a URL. ( hence the [] ) It is indirectly identified by  
the pair of properties rsa:public_exponent and rsa:modulus which  
relate public keys to numbers.


>> From a security analysis POV, it's a worthless piece of nothing at  
>> all; except that - like formalized "ephemeral" certs in the SSL  
>> protocol - it has an interesting side-effect. It causes the RP's  
>> SSL server to have knowledge that the user possessed and used a  
>> private key, with its pretty canonical id (the public key bytes).
>
> Now, we know from foaf+ssl, that if an SSL server [securely]  
> resolves that incoming, canonical publickey id against a foaf file  
> at the (direct) webid hinted at in the client cert blog, the  
> fragment in the webid can properly identity which objects in the  
> triple set one is after (for further processing by the layer 7 stack  
> entity contributing to handling the https protocol). With a bit of  
> triple store processing, even Peter can obtain the indirect openid  
> (of which one abstract variant is the HXRI/XRI), and now talk to an  
> OP to verify identifies (of all the sorts).

yes, you can use the openid relation in the foaf file, and do  
something with that, such as verify identities. That is what the foaf 
+ssl OpenId provider I mentioned before does.

http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community

When the user logs into such an OpenId provider using foaf+ssl, the OP  
having fetched the foaf file to verify identity, find the openid in  
that graph, then gets the openid page and verifies that it points to  
the foaf file as well as to the OP.

> Now that's all well and good. And, I know your focus is access  
> control thereafter, using foaf and linked networks of foaf files to  
> ultimataly guard access to the resource identified in the https URL  
> that started the whole sequence.
>
> But, for me, the benefit is closer to home- coming down to making  
> websso adoptable. I've got OPs trying to induce me to rely on THEIR  
> names for the public - who do want to talk to my customers portal  
> sites. But, this produces a LEVEL of dependency Im uncomfortable  
> with. The security architect in me HAS to prepare for a breakdown in  
> the relationship of a particular member of the public with Google OP  
> (say). And that breakdown needs to have NO impact on the public's  
> ongoing PRIVATE relationship with my customers. (And, probably they  
> also don't want the likes of Google as OP knowing too much of their  
> timing of or other history of interactions -  since they and all  
> other search engines will endeavor to crawl it, correlate it and  
> publish it to the world, given half a chance - compromising the  
> trust between realtor and client)

yes that makes a lot of sense.

>
> Now, openid 1 had it good (for me), as RPs performed and controlled  
> the (cross domain) name mapping. That is, as RP I had ultimate  
> control. I could even easily outsource that name mapping to an i- 
> broker, managing the XRDs doing the name mappings. Today, with  
> openid2, I no longer have this control (even in the latest, fancy  
> signed XRDs from Google Apps for domains)

Oh, I see.

hmm. In OpenId 1 I thought that you had to use one of the Identity  
Provider linked to from the openid page. I thought OpenId 1 did not  
work with XRDs . How did the brokering work? Just a man in the middle  
you trusted I suppose who could cover the identity of the real service  
asking for authentication, I presume.


> Im hoping that in tying direct, indirect and abstract identifiers  
> back together SPECIFICALLY at the behest of _RPs_, foaf+ssl+openid  
> can redress the balance of power - so RPs can once again control  
> their own dependencies. I suspect this is critical to RPs choosing  
> in general to adopt or not to adopt websso "for transactions beyond  
> those that don't matter"

Could well be.

foaf+ssl could by itself go even further. There are only three things  
that need to be running for a foaf+ssl identification service to work.

1. The client machine that makes the connection
2. The server (RP) it is trying to connect to
3. the server serving the foaf file

Since The server serving the foaf file, can be on the same machine as  
the client, then there are only two machines that need to be  
functioning and alive: the client machine and the RP.

Perhaps that opens yet further possibilities.

Henry

>
>
> -----Original Message-----
> From: hjs at bblfish.net [mailto:hjs at bblfish.net] On Behalf Of Story  
> Henry
> Sent: Sunday, August 30, 2009 9:50 AM
> To: Peter Williams
> Cc: openid-general at lists.openid.net; John Bradley
> Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update  
> (August 2009)
>
>
> On 30 Aug 2009, at 17:28, Peter Williams wrote:
>> I took my counsel on fragments from http://java.sun.com/javase/6/docs/api/java/net/URL.html?is-external=true
>>
>> "This fragment is not technically part of the URL. []"
>
> That is sleight of hand in the Java documentation. That Java
> documentation is not authoritative on the meaning of URLs. That's an
> implementors point of view. :-)
>
>
>> I'll guess that the writers were simply trying to capture a less-
>> than-formal notion of URLs from earlier generations of the web -
>> that we also apply in openid.
>
> Yes, the Java URL class is designed to fetch a document, and to do
> that it follows the HTTP protocol, which does indeed indicate that one
> has to strip the #tag . So at that level it is correct. The Java URL
> class is focused on that behavior. It does not take the bigger
> architectural picture into consideration.
>
>> I do now see we have philosophical different here, which may make
>> make it hard for webids and openids to work well together (if we all
>> get too tied to formal models, and starting citing abstract
>> definitions).
>
> We need to avoid coming to a conclusion too quickly here. The JavaDoc
> does not exclude the IETF definition. It is just captures a part of  
> it.
>
> OpenIds and WebIds are very compatible. As I mentioned in my previous
> email, foaf has the foaf:openid relation that relaties an agent to his
> webid, in a way very similar in which it relates an foaf:Agent to a
> email box with the foaf:mbox relation, or a foaf:Agent to a home page
> with the foaf:homepage relation. Each of these relations is an
> indirect identifier of an agent.
>
>>
>> We need to avoid frustration over such things. We probably all
>> remember frustrating some poor guy over his desire for the openid
>> spec to mandate and require http correctness, over applying 301s for
>> persistent name changes, etc.
>
> I am finding that people coming to the semantic web via foaf+ssl get
> these concepts quite quickly. We have php developers who went from
> knowing nothing about the semantic web to writing foaf+ssl servers.
> The documentation and tools are now good enough that one can get going
> quite easily.
>
>> I'm not interested in engaging in world where, like semweb and XRI/
>> XDI, webids are competing with openids for adoption (for this or
>> that reason).
>
> There is no competition. WebIds are direct identifiers, OpenIds are
> indirect identifiers. They fulfil different roles, and are useful in
> different ways. As I mentioned in my blog "Join the foaf+ssl community
> and get OpenId for free" we have created a proxy OpenId service that
> uses foaf+ssl authentication.
>
> http://blogs.sun.com/bblfish/entry/join_the_foaf_ssl_community
>
>
>> Once Microsoft acts, I will have confidence that 100Million
>> consumers can talk to our 1 millions realtor's portals, using openid
>> for websso - aka problem solved. To go the next level for access
>> control and trust management, with webids and foaf perhaps, some
>> compromises are going to have to be fashioned.
>
> I don't think we need to compromise - and I don't mean that we have to
> fight each other. :-) OpenIds and WebIds are compatible, so there is
> no strain.
>
>
>        Hope this helps,
>
>        Henry
>
>
>> -----Original Message-----
>> From: hjs at bblfish.net [mailto:hjs at bblfish.net] On Behalf Of Story
>> Henry
>> Sent: Sunday, August 30, 2009 6:24 AM
>> To: Peter Williams
>> Cc: openid-general at lists.openid.net; John Bradley
>> Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update
>> (August 2009)
>>
>> On 30 Aug 2009, at 05:50, Peter Williams wrote:
>>
>>> What Im trying to recall is the markup used commonly for a control
>>> _tree_, in your typical ASP.NET rendering of a server side object
>>> set.
>>>
>>> Perhaps its something like http://foo.com/#form$element$elementchild
>>> where everything following the # is a (compound) "tag". By
>>> definition the semantics of any such tag are "resource-defined"-
>>> which ASP.NET properly defined for its resources. Under the formal
>>> interpretation, the fragment is not (and this is counter intuitive)
>>> not part of the URI!!
>>
>> No, that is incorrect. A URL with a # fragment is a URL.
>>
>> see:
>> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components
>>
>> It is just that the meaning of that URL is specified by the
>> representation returned. see section 3.5 where it says:
>>
>> [[
>> The fragment identifier component of a URI allows indirect
>> identification of a secondary resource by reference to a primary
>> resource and additional identifying information. The identified
>> secondary resource may be some portion or subset of the primary
>> resource, some view on representations of the primary resource, or
>> some other resource defined or described by those representations.
>> ]]
>>
>> So the following are two different URIs:
>>
>> http://labs.apache.org/webarch/uri/rfc/rfc3986.html
>> http://labs.apache.org/webarch/uri/rfc/rfc3986.html#components
>>
>> The first one refers to an html document, which is returned by a
>> successful HTTP GET request.
>> The second refers to a part of the first document, because the html  
>> of
>> the returned document contains the following html:
>>
>> <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5.</a>&nbsp;<a
>> name="fragment" href="#fragment">Fragment</a></h2>
>>
>> and html specifies that id fragments refers to document parts.
>>
>> Similarly
>>
>> http://bblfish.net/people/henry/card
>>
>> refers to an rdf document, more precisely a
>> foaf:PersonalProfileDocument, which is a subclass of documents. On  
>> the
>> other hand
>>
>> http://bblfish.net/people/henry/card#me
>>
>> refers to me, the person. This is specified by the representations
>> returned by the first URI.
>>
>>> I know I wrote user control for asp.net that spat this kind of
>>> markup out, server side. I just don't remember the syntax.
>>>
>>> And I any case, a self-signed cert can have as many URIs as it
>>> likes, one per extended subject field: each a "synonym".
>>>
>>> If one cannot post-fix the hash to "qualify" the webid, one can
>>> always add another URI... that is the webid's "synonym" - used much
>>> as in the XRD world of canonical-ids, to ensure one has an
>>> unambiguous reference point (for validation logics).
>>
>> Given that the beginning of your argument is mistaken, I am not  
>> sure I
>> follow you anymore here.
>>
>>>
>>> Anyways, think about the main point some more. The point was: that
>>> which openid2 removed from openid1 (rp-side name linking) CAN be put
>>> back - especially if the larger OPs refuse to support openid2-style
>>> vanity delegation.
>>
>> Sorry, I did not follow the story about vanity delegation.
>>
>> Just as a matter of interest, in case it is relevant here, in foaf  
>> one
>> can indirectly identify a person via their OpenId.
>>
>> $ cwm  http://bblfish.net/people/henry/card --ntriples | grep -i '/
>> openid'
>>
>> <http://bblfish.net/people/henry/card#me> <http://xmlns.com/foaf/0.1/openid
>>> <http://bblfish.net/> .
>>
>> <http://bblfish.net/people/henry/card#me>     <http://xmlns.com/foaf/0.1/openid
>>> <http://openid.sun.com/bblfish> .
>>
>> This is because foaf:openid is defined as being a
>> owl:InverseFunctionalProperty. It only one thing can have that
>> relation to the same openid.
>>
>> Can you tell me what you are trying to achieve without using too many
>> technical terms :-)
>> I'll try to explain how one can do that in the foaf world.
>>
>> Henry
>>
>>
>>>
>>>
>>> -----Original Message-----
>>> From: hjs at bblfish.net [mailto:hjs at bblfish.net] On Behalf Of Story
>>> Henry
>>> Sent: Saturday, August 29, 2009 8:29 PM
>>> To: Peter Williams
>>> Cc: John Bradley; openid-general at lists.openid.net
>>> Subject: Re: [OpenID] Windows Live ID OpenID CTP Status Update
>>> (August 2009)
>>>
>>>
>>> On 30 Aug 2009, at 04:39, Peter Williams wrote:
>>>
>>>> Can we make the webid that we put in the self-signed cert have the
>>>> form
>>>>
>>>> http://foaf.com/peter.rdf#me#<hash> ?
>>>
>>> Don't think so. That's an invalid URL I believe. (I may be wrong)
>>>
>>> It is not good architecture to put meaning into URLs such that
>>> protocols depend on those - which is not to say that they should not
>>> be humanly readable. That ties URLs between sites much too closely
>>> together, and I believe unnecessarily.
>>>
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-general
>>
>
> _______________________________________________
> general mailing list
> general at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-general

More information about the general mailing list