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

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

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

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

Received on Tuesday, 20 November 2012 12:15:54 UTC