W3C home > Mailing lists > Public > public-webid@w3.org > November 2012

Re: Principal term choice - Was: Re: Identity interoperability

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 20 Nov 2012 16:50:12 +0100
Cc: Olivier Berger <olivier.berger@it-sudparis.eu>, public-webid <public-webid@w3.org>
Message-Id: <5E14FCBD-AB5E-4429-9B3C-45678505A4C4@bblfish.net>
To: Kingsley Idehen <kidehen@openlinksw.com>
Thanks for those extra spec quotations Kingsley. You will notice that none 
of these definitions are very clear - they are not formally defined and so 
leave open some formal definitions which I am trying to put together here.

Notice that these definitions always speak of the "Principal resource". 
Those are  2 words. You have the Principal which is the string, and the 
principal resource which is the document  which we call the WebID Profile 
in the case of WebID. Java allows public keys to be principals, and it 
is not clear there what the resource is on the web for it.

So let me try to formalise the definition by working from what the
specs say. 

What is clear is that in Java and the IETF specs we must have a way to 
construct a principal from a string or some other object ( a public key 
for example, in the case of Java definition)

   val timbl =  WebIDPrincipal("http://www.w3.org/People/Berners-Lee/card#i")

From this we seem to have a way to get to a resource ( for the ietf WebDAV,
CALDav, etc, )

   val doc: URL = timbl.resource
that covers the notion of a principal resource. We could write that like this

   timbl.resource == <http://www.w3.org/People/Berners-Lee/card>

I think this covers what the IETF specs say below.

Note the IETF specs are quite old, and pre semantic web, so they 
just in my view it is quite confusing for them to speak about these

  Given that in the identity interoperability spec I want to speak (as Java
does) of WebID Principal, OpenID Principal, OAuth Principal, public key principals...
I don't think that is counter to what the IETF specs say either, since it is
extreemly open.

So we can have the OpenID principal

   val hjsOID = OpenIdPrincipal("http://bblfish.net/")

would have

   hjsOID.resource == <http://bblfish.net/> .

and then

   val hjsWebID = WebIDPrincipal("http://bblfish.net/#hjs")

would have

   hjsWebID.resource == <http://bblfish.net/> .

Also why not an e-mail principal

   val hjsMbox = MBoxPrincipal("henry.story@bblfish.net")

we have perhaps

   hjsMbox.resource == <mailto:henry.story@bblfish.net>

Note that

   hjsWebID.resource == hjsOID.resource

even though

   hjsWebID =/= hjsOID

I think this is ok, because a Principal also has another function called ref
that identifies the thing the Principal is directly about

   hjsWebID.ref == <http://bblfish.net/#hjs>

   timbl.ref ==  <http://www.w3.org/People/Berners-Lee/card#i> 

   hjsMbox.ref == <mailto:henry.story@bblfish.net>

Interestingly here

   hjsMbox.ref == hjsMbox.resource

Now here the question remains: How does this identify the user!? The IETF spec
and the Java ones also have a notion of this identifying a user in the end.

So my argument here is that each type of principal is asociated with a function
from Principal to User/Subject. For each type of principal this function can
also be determined by a slot in a SPARQL query such that by replacing the ?ref
variable in the sparql query you get the subject id back.

For a MBoxPrincipal the sparql query is 

SELECT ?subject
WHERE { ?subject foaf:mbox ?ref }

For a OpenID Principal the sparql query is

SELECT ?subject
WHERE { ?subject foaf:openid ?ref }


So we  simply have found that the notion of a principal in the IETF is just 
something  that identifies a user, but in a way that is just more complex than the 
pure semantic reference relation. Clearly a public key does not refer to a subject
directly. In the IETF specs that relation is pushed under the carpet  by the notion 
of a "representation".

And it is this notion of representation that needs to be clarified. That is what
the Identity Interoperability spec is trying to do

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

> On 11/19/12 7:44 PM, Henry Story wrote:
>> In Java there is the Principal class
>>   http://docs.oracle.com/javase/1.4.2/docs/api/java/security/Principal.html
>> [[
>> This interface represents the abstract notion of a principal, which can be used to represent any entity, such as an individual, a corporation, and a login id.
>> ]]
>> You can see the subclasses there are JMXPrincipal, and  X500Principal
>> There is the Subject class
>>    http://docs.oracle.com/javase/1.4.2/docs/api/javax/security/auth/Subject.html
>> [[
>>  Subject represents a grouping of related information for a single entity, such as a person. Such information includes the Subject's identities as well as its security-related attributes (passwords and cryptographic keys, for example).
>> ]]
>> Next:
>>   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 in
>>    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.
>> ]]
>> Note:
>>  - a Principal is a "network resource" that represents an actor.
>>  - "a uri of any scheme may be used to identify a principal resource".
>>  a network resource is NOT a subject. It _represents_ a subject - which is different.
>> 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.
>> In the above a Principal is a network resource. I have shifted it to be a type of identifier...
>> I don't think the use is very clear anywhere. One could call the one the Principal String, the
>> other the Principal. Essentially the point is that these things don't denote the Agent directly,
>> only indirectly.
> Henry,
> You've referenced Java and one IETF spec. As you know, there are other specs from the IETF offering alternative views about this matter, in the realm of security.
> CalDAV [1]:
> " Support for MKCALENDAR on the server is only RECOMMENDED and not
>   REQUIRED because some calendar stores only support one calendar per
>   user (or principal),

user ( or principal ): that is not saying they are synonymous terms, just
that some calendars only support one calendar per login id ( principal )
because they don't have sufficient semantic knowledge to owl:sameAs the
referents of those principals.

> and those are typically pre-created for each
>   account.  However, servers and clients are strongly encouraged to
>   support MKCALENDAR whenever possible to allow users to create
>   multiple calendar collections to help organize their data better.?
> CardDAV [2]:
> " Namespace:  urn:ietf:params:xml:ns:carddav
>   Purpose:  Identifies the URL of any WebDAV collections that contain
>      address book collections owned by the associated principal
>      resource. "
> Note: principal resource phrase.

yes "principal resource". Notice that those are two words. We have


and the principal resource:


Note that in Java they use Principal even for Public keys, where there really is no determinate
way to find the resource for the key.

> CORBA [3]:
> "The security functionality defined by this specification comprises:
> Identification and authentication of principals (human users and objects that need to operate under their own rights) to verify they are who they claim to be. "
> WebDAV [4]:
> "WebDAV [RFC4918] is an extension to HTTP [RFC2616] to support
>   improved document authoring capabilities.  The WebDAV Access Control
>   Protocol ("WebDAV ACL") [RFC3744] extension adds access control
>   capabilities to WebDAV.  It introduces the concept of a "principal"
>   resource, which is used to represent information about authenticated
>   entities on the system."
> The definition above is the closest to what you seek i.e., a "principal" resource. Like other Web resources, you can denote this kind of resource with a URI (which may or may note resolve to anything) .

yes, see my response above.

> Links:
> 1. http://tools.ietf.org/html/rfc4791 -- CalDAV
> 2. http://tools.ietf.org/html/rfc6352 -- CardDAV
> 3. http://www.omg.org/technology/documents/security_spec_catalog.htm -- CORBA
> 4. http://tools.ietf.org/html/rfc5397 -- WebDAV.
> Kingsley
>> On 19 Nov 2012, at 21:55, Olivier Berger <olivier.berger@it-sudparis.eu> wrote:
>>> Hi.
>>> Henry Story <henry.story@bblfish.net> writes:
>>>> I have defined Principal much more carefully here
>>>> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability#logical_relationships_of_principals
>>> Maybe it's just my poor knowledge of the english language... but could
>>> you point me to a reference definition of "Principal" that would apply
>>> here, for instance in http://en.wiktionary.org/wiki/principal ?
>>> Just for the sake of clarity, I guess we should prefer common language
>>> terms as much as possible...
>>> Or maybe it's just me ?
>>> Kind regards,
>>> -- 
>>> Olivier BERGER
>>> http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
>>> Ingenieur Recherche - Dept INF
>>> Institut Mines-Telecom, Telecom SudParis, Evry (France)
>> 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

Social Web Architect

Received on Tuesday, 20 November 2012 15:50:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:45 UTC