Re: Identity interoperability

On 13 Nov 2012, at 16:41, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> So you have principals for WebID, OpenID, and others? Why not an identity that's verifiable using a variety of authentication protocols? The IFP semantics pretty much infers that. 

yes, because different Principals refer to different things. So the type of the principal tells me which slot I need to
place it in in an RDF graph such as the one I wrote up here:
http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .

<http://logic.edu/webids/jz#i> a foaf:Agent;
    foaf:mbox <mailto:jz@logic.edu>;
    foaf:openid <http://logic.edu/webids/jz>;
    cert:key [ a cert:RSAPublicKey;
             cert:modulus "cb24ed85d64d794b69c701c186acc059501e856...."^^xsd:hexBinary;
             cert:exponent 65537 ] .

a mailto principal gives me one way to identify <http://logic.edu/webids/jz#i>
via the foaf:openid relation. But I should not confuse the WebID referent
<http://logic.edu/webids/jz#i>
which directly identifies the agent, and the mailbox referent
 <mailto:jz@logic.edu>
or the home page referent
<http://logic.edu/webids/jz>
These URIs all refer to different things. I can use all of these to identify the same subject, but not using the same procedures, and not in the same way. 

Hence to make things really clear we have to functions for every type of Principal. For an email
principal:

1. a function from the string ( e.g. "jz@logic.edu" ) to a mailbox <mailto:jz@logic.edu>
    ( that is useful for example when taking a Principal out of a BrowserID certificate)
   call this funtion Ref.   so Ref("jz@logic.edu") = <mailto:jz@logic.edu>

2. a function from the mailbox to the subject ( the owner of the mailbox ) which in the very
vague language of WebDAV auth is termed the thing the principal represents. Call this function 
Subj. So Subj(Ref("jz@logic.edu") ) is the agent that is authenticating. 

You can see that without  semantics those distinctions look like they are splitting hair in 4. But 
when you write it out in foaf it is clear why this is useful. It allows you to distinguish mailboxes and
people.

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .

<http://logic.edu/webids/jz#i> a foaf:Agent;
    foaf:mbox <mailto:jz@logic.edu>.


> 
> 
>> 
>> I think that works neatly, is compatible with the above WebDAV definition, but alows us to be precise by distinguishing names, their referents, and the relation that referent is to the subject.
> 
> My problem is that I see:
> 
> 1. Entity -- a thing 
> 2. URI denoting an Entity
> 3. Document that describes an Entity via its URI in an Entity Relationship Graph 
> 4. Use of indirection (explicit or implicit) to associate a URI denoting an Entity with a Document bearing the graph based content that describes said entity. 
> 
> #4 is the essence of Linked Data. Ultimately why URIs (Names as Names) work better than URLs (Addresses as Names). 

What is your problem as it relates to this thread?  I don't think that any of these definitions goes against Web Architecture of

0. an identifier ( some string ) following the URI syntax (Uniform Resource Identifier)
1. That identfier refering to resource ( some thing ), the Ref(uri) = thing
2. that thing being in a number of relations to other things ( say a person owning a mailbox ), each relation can be
   named by a different URI, eg http://xmlns.com/foaf/0.1/mbox
3. the sense of the URI being findable automatically either by removing the #tag part of the URI, or via 303 redirection
  such that the owner of the URI namespace defines the initial/seed meaning of the term.

> 
>> I think we can get some very neat logic out of this, in a way that is much clearer than what the ( very interesting ) WebDAV Auth RFC is trying to do. ( thanks for those
>> pointers )
> 
> Okay, we'll get there for sure :-)

Social Web Architect
http://bblfish.net/