[OpenID] [foaf-dev] Can OpenID identify a person

Dan Brickley danbri at danbri.org
Thu Jun 7 20:50:46 BST 2007

Peter Williams wrote:
>>> Some SemWeb people (notably TimBL) take care to have a 
>> "non-Document"  
>>> URI for themselves, distinct from their homepages. eg.  
>>> http://example.org/foaf#memyself  ... but I don't know any usage of 
>>> these as OpenID URIs. In fact I don't know if an OpenID can have a 
>>> #hashblahblah section, or how that interacts with common 
>> OpenID tools, 
>>> services and practice.
>> This is impossible, because # defines a section of the 
>> document that is chosen locally and there can be only one 
>> declaration of an OpenID per document.
> Can we go through this more carefully, please?
> My understanding was, that the user-centric URI is selected entirely by
> the individual, who "controls" it. (a) it must be valid URI syntax; no
> other constraints are specified (b) it may or may not have a
> globally-resolvable domain-name component. If one wants "100% control"
> over the URI and its portability, one does not use a domain name
> CONTROLLED BY a domain name registrar. The same control dynamics also
> apply to the XRI variant OpenIDs.

w.r.t. XRI, same presumably goes for uuid:, urn: and various other 
non-http: URI schemes? Is there any reason to consider XRIs somehow 
apart from the general URI model? Aside from their policy or technical 
attractiveness, I mean: can non XRI experts treat XRIs as "just" a URI 
scheme? At least in the context of RDF / OpenID discussions? I guess 
it's time I read up on XRIs...

> My understanding was also:- To identify the OP instance(s) "managing"
> your URI/XRI (for this month), the URI must be the basis for the normal
> openid Consumer lookup - to locate the OP servers' address/URLs. How
> globally resolvable that location service shall be...is a function of
> the resolvability of the OpenID URI name. 

Yup, makes sense to me. On the Web in general, dereferencing is a 
privilege not a right. It is a very useful privilege though :)

> Nothing however requires the Consumer to use a global resolution service
> (based on public domain names and public XRI resolvers, probably), nor
> for the OpenID to be globally resolvable. One could be in a private
> OpenID management domain, where local knowledge is required by the
> OpenID Consumer ...to complete username->svcprovideraddr resolution.

An RDF notation for this information might be one useful way for 
exchanging that local knowledge (eg. via SPARQL queries
http://www.w3.org/TR/rdf-sparql-json-res/ ).

> My understanding of XRDS was:- XRDS service-locator element in the
> simple XML file are intended to help out in the above, for both the
> public and the n private management domains where a URI/XRI are being
> "managed." However, the XRDS document is at most non-authoritative,
> being insecurely transferred. It's a "hint" process.

 From what you say, ... my understanding of the contraints on a FOAF (or 
perhaps other RDF) representation of OpenID include:

  * that we should be careful *not* to assume http: URIs are always used
  * or that de-referencable via public infrastructure is the only 
deployment mode for OpenID
  * or that all OpenIDs can be considered identifiers of documents and 
only indirectly, of people

I think this is consistent with a new foaf:openid property in FOAF that 
has a domain of foaf:Agent and range of foaf:Document. It would:

  * allow the document to be identified by any URI scheme (standard 
practice in RDF)
  * not imply complete coverage: there might be uses of OpenID it 
doesn't fit
  * not describe all the intimate details of delegation, resolution etc
  * not imply that all OpenIDs identify people; it would imply however 
that anything with a foaf:openid is an "Agent" (a pretty broad 
category), and remain agnostic about whether there were other cases.

I'm not 100% convinced about defining the range of foaf:openid as 
Document, but from what I hear, it sounds like it would cover current 
deployed practice. For non RDF-heads, the "range" of a property is the 
class of things that you can expect as values of the property (while 
"domain" is the class of thing the property is applied to). The nice 
diagram in the old MCF spec explains it quite visually, see
http://www.textuality.com/mcf/NOTE-MCF-XML.html#sec2. (MCF is an ancient 
ancestor of RSS/Atom).

A question about the spec ...
In http://openid.net/specs/openid-authentication-1_1.html

"An Identifier is just a URL. The whole flow of the OpenID 
Authentication protocol is about proving that an End User is, owns, a URL."

Here we have both "is" and "owns", but later

"Verified Identifier:
     An Identifier that the End User has proven to a Consumer that they 

Is ownership the dominant concept?

I can be said to "own" http://danbri.org/ and there are ways to verify 
that. Whereas whether I "am" that same thing in some verifiable and 
non-metaphorical sense feels a bit too philosophical a question.

What I take away from reading that spec is a reasonably close fit to
http://www.w3.org/TR/webarch/#indirect-identification in the Web 
Architecture, ie. that this is a case of indirect identification via an 
intermediary document (in my case, my homepage).

Are there members of the openID community who will insist that OpenID 
URIs really are direct identifiers (in the sense of 
http://tools.ietf.org/html/rfc3986) for flesh and blood people? If 
that's the design, we should take care not to step on toes when 
reflecting it into RDF/FOAF...




More information about the foaf-dev mailing list