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

Sun Aug 30 17:32:11 UTC 2009

So that was useful.

Webid are direct identifiers
Openid are indirect identifiers.

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

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.

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

>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).

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)

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)

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"

-----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
>