Re: Identity interoperability

On 11/13/12 10:18 AM, Henry Story wrote:
> Kingsley, I am asking for the XG mailing list to be closed. Can you 
> move to send
> mail to the CG so that people can get the full conversation? The mails 
> are forwarded
> to the XG anyway.

No sure which CG you are referring too. Anyway, I've added RWW for now.
>
> On 13 Nov 2012, at 15:46, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>> On 11/13/12 9:36 AM, Henry Story wrote:
>>>
>>> On 13 Nov 2012, at 15:11, Kingsley Idehen <kidehen@openlinksw.com 
>>> <mailto:kidehen@openlinksw.com>> wrote:
>>>
>>>> On 11/13/12 7:44 AM, Melvin Carvalho wrote:
>>>>>
>>>>>
>>>>> On 13 November 2012 13:28, Kingsley Idehen <kidehen@openlinksw.com 
>>>>> <mailto:kidehen@openlinksw.com>> wrote:
>>>>>
>>>>>     On 11/13/12 6:43 AM, Henry Story wrote:
>>>>>
>>>>>         Hi as promised during our last teleconf [1] I put together
>>>>>         an Identity Interoperability wiki page
>>>>>
>>>>>         http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability
>>>>>
>>>>>         This is the beginning of something that could end up
>>>>>         becoming a very large project, so it is
>>>>>         clearly just a beginning, with some initial pointers.
>>>>>
>>>>>              Henry
>>>>>
>>>>>         [1] http://www.w3.org/2012/11/09-webid-minutes.html
>>>>>
>>>>>         Social Web Architect
>>>>>         http://bblfish.net/
>>>>>
>>>>>
>>>>>     Great Wiki doc!
>>>>>
>>>>>     OpenID is based on XRD documents, you can make whatever claim
>>>>>     you want via the content of said document type.
>>>>>
>>>>>     Example:
>>>>>     http://linkeddata.informatik.hu-berlin.de/uridbg/index.php?url=http%3A%2F%2Fkingsley.idehen.net%2Fods%2Fdescribe%3Furi%3Dacct%3Akidehen%40openlinksw.com&useragentheader=&acceptheader=
>>>>>     .
>>>>>
>>>>>
>>>>> Nice page!
>>>>>
>>>>> So the "principle" in OpenID terms would be the "subject", in this 
>>>>> case acct:kidehen@openlinksw.com 
>>>>> <mailto:acct%3Akidehen@openlinksw.com> using webfinger?
>>>> Yes.
>>>>
>>>> 'Principal' and 'Subject' are synonyms re., terminology used to 
>>>> denote what an identity claims graph describes.
>>>
>>> I don't think so.
>>>
>>> In Java the class Subject is reserved for the collection of all the 
>>> different principals that have been proven refer to an agent.
>>
>> This isn't about Java.
>
> I know it is not about Java. I point to java usage because that is a 
> very widely deployed system with 10 of millions of developers, which 
> shows a lot of precedence for using the term this way.

That's a small number compared to the realm of non Java developers that 
work on identity and security matters :-)

>
>>
>> I am the Subject of my X.509 certificate. Ditto my FOAF profile 
>> document. In both cases, I am also the principal. In both cases I can 
>> denote myself using a URI.
>
> I am trying to use the word principal differently, in order to make a 
> distinction between the string identifier and the referent of the string.

Yes, but when we say a URI denotes an Entity don't we cover that? The 
Entity in question has certain characteristics (attributes) each of 
which are also denoted using URIs. Ultimately, we end up with an entity 
relationship graph endowed with explicit semantics, when the RDF model 
is in play.

> Since you already have the word Subject, there is no need for the word 
> Principal to mean the same thing. Use the word Subject when you mean 
> the subject, and allow us to use principal to talk about the literal 
> string.
>
>>
>>> I think therefore that subject is the thing identified by any 
>>> principal, not the string that is the principal.
>>
>> I didn't say anything about strings/literals.
>
> That is the definition I am putting forward.

You can put it forward, but this sentence doesn't add clarity to the 
matter at hand:
I think therefore that subject is the thing identified by any principal, 
not the string that is the principal.

The matter at hand in your example is how semantics enable one compute 
co-reference by IFP property values. If you recall, this was one of the 
examples I spelled out to Ben a long time ago. We don't have to keep on 
playing around with terminology like this. What we have works, it just 
needs embellishment from working examples.

We are trying to demonstrate how uniqueness is discerned from the claims 
in a document. This document describes an entity. The entity in question 
is the subject of the description document. The content of this document 
is an RDF based entity relationship based graph pictorial where 
attribute=value pairs coalesce around the URI that denotes the 
description subject.

>
>>
>>>  Subject is I think widely understood to be the subject of a 
>>> connection, the agent itself. Principal is a very technical term, 
>>> which I use here to identify the string identifier itself.
>>
>> Principal is used across many protocols (CardDAV, CalDAV, many 
>> others) and it means the identity of some entity that can be 
>> authenticated.
>
> Can you find me usages for each of these from specs?  ( ah I see you 
> have below ... )
> Also "the identity of some entity that can be authenticated" is 
> usually just a string identifier. Most of these systems don't think 
> semantically, so if they don't specify it you should assume they are 
> thinking syntactically.

They always think semantically, the problem is that said semantics are 
implicit thus not discernible from associated data. That's the problem. 
Nobody crafts systems devoid of semantics, they just don't put the 
semantics in the data. This is where RDF is different. This is why RDF 
is useful.

>
>>>
>>>
>>> I have defined Principal much more carefully here
>>> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability#logical_relationships_of_principals
>>
>> I'll take a look. But it's best to use these terms in line with usage 
>> elsewhere.
>>
>> Random excerpt from vCard extensions spec [1]:
>>
>> " Support for creating address books on the server is only RECOMMENDED
>>    and not REQUIRED because some address book stores only support one
>>    address book per user (or *principal*), and those are typically pre-
>>    created for each account."
>
> yes, but that does not mean they are not confused themselves. Don't 
> forget most specs
> don't make clear semantic distinctions between names and referents.
> The above spec refers to this one constantly for its notion of Principal
>
> http://tools.ietf.org/html/rfc3744#section-2
>
> [[
>     A principal is a network resource that represents a distinct human or
>     computational actor that initiates access to network resources.
>     Users and groups are represented as principals in many
>     implementations; other types of principals are also possible.  A URI
>     of any scheme MAY be used to identify a principal resource.  However,
>     servers implementing this specification MUST expose principal
>     resources at an http(s) URL, which is a privileged scheme that points
>     to resources that have additional properties, as described inSection  <http://tools.ietf.org/html/rfc3744#section-4>
>     4  <http://tools.ietf.org/html/rfc3744#section-4>.  So, a principal resource can have multiple URIs, one of which has
>     to be an http(s) scheme URL.  Although an implementation SHOULD
>     support PROPFIND and MAY support PROPPATCH to access and modify
>     information about a principal, it is not required to do so.
>
>     A principal resource may be a group, where a group is a principal
>     that represents a set of other principals, called the members of the
>     group.  If a person or computational agent matches a principal
>     resource that is a member of a group, they also match the group.
>     Membership in a group is recursive, so if a principal is a member of
>     group GRPA, and GRPA is a member of group GRPB, then the principal is
>     also a member of GRPB.
> ]]
>
> I think the above is confusing (if not confused) anyway. Here a 
> Principal is a "network resource"
> that represents an actor. Also "a uri of any scheme may be used to 
> identify a principal
> resource".

Yes, they are confused since they don't think in terms of denotation 
beyond network resources, an eternal problem.

>
>
> Note that a network resource is NOT a subject.

Correct, and I've never assumed it was.

> It _represents_ a subject - which is different.

Ditto.

> That is why I have 2 functions:
>  1. a function that goes from a string to a URI referent ( usually a 
> network resource I will add)
>  2. a function from that uri referent to the subject.
>
> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability#logical_relationships_of_principals
>
> for different types of principals there are different such functions. 
> An OpenID
> principal has the foaf:openid relation from the subject to the 
> referent of the principal.

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.


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

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


Kingsley
>
>
>>
>>
>> The term 'User' denotes an entity that a system would need to verify .
>>
>> Links:
>>
>> 1. http://tools.ietf.org/html/rfc6352#section-7.1
>>
>>
>> Kingsley
>>
>>
>>>
>>>
>>>
>>>>
>>>> Kingsley
>>>>>
>>>>>
>>>>>     -- 
>>>>>
>>>>>     Regards,
>>>>>
>>>>>     Kingsley Idehen
>>>>>     Founder & CEO
>>>>>     OpenLink Software
>>>>>     Company Web: http://www.openlinksw.com
>>>>>     <http://www.openlinksw.com/>
>>>>>     Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>>>>     <http://www.openlinksw.com/blog/%7Ekidehen>
>>>>>     Twitter/Identi.ca <http://identi.ca/> handle: @kidehen
>>>>>     Google+ Profile:
>>>>>     https://plus.google.com/112399767740508618350/about
>>>>>     LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -- 
>>>>
>>>> Regards,
>>>>
>>>> Kingsley Idehen	
>>>> Founder & CEO
>>>> OpenLink Software
>>>> Company Web:http://www.openlinksw.com
>>>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
>>>> Twitter/Identi.ca  <http://identi.ca/>  handle: @kidehen
>>>> Google+ Profile:https://plus.google.com/112399767740508618350/about
>>>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>>>
>>>>
>>>>
>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web:http://www.openlinksw.com
>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca  <http://Identi.ca>  handle: @kidehen
>> Google+ Profile:https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen