Re: API (and identity) thoughts

> On 29 Jan 2015, at 04:42, James M Snell <jasnell@gmail.com> wrote:
> 
> Sorry, this is going to be long.

I pretty much agree with the contents of your post, including the line
above, so that to avoid filling inboxes I'll pass it here by reference
rather than by value - to use a well known programming distinction:
http://lists.w3.org/Archives/Public/public-socialweb/2015Jan/0082.html

I'd just add to your description that we need access control on resources,
and that these should also be something a client can find by 
"following his nose" [1]. (I'll get to that at the end.)

This brings me to your earlier posts about Identity which I find 
gets a little confusing. From experience it is best when working on
this subject not to delve into psychology ( what allegedly people find 
easy/difficult to understand etc ), but to stick to logic, and use 
clear well defined terms, so that at least we understand each other
and then we can come to a simple consensus that will allow us all 
to move forward happily. Let me pave the way to the consensus...

URIs
----

For that I like to use the attached schema [2] to illustrate the 
sense/reference distinction used in logic and that we inherit from 
Frege.





Essentially URIs or IRIs are string that _refer_ to things in the world - that
is what the R in "URI" stands for. In the Web 1.0 the http URIs mostly refered
to web pages. mailto: URIs refer to mailboxes ( that's from the spec [3] ). Any URI
can refer to anything according to the URI spec via #tags as specified by 
RFC3986  ( the URI spec ) §3.5 . In particular

[[
   The fragment identifier component of a URI allows indirect
   identification of a secondary resource by reference to a primary
   resource and additional identifying information.  The identified
   secondary resource may be some portion or subset of the primary
   resource, some view on representations of the primary resource, or
   some other resource defined or described by those representations.  
   A fragment identifier component is indicated by the presence of a
   number sign ("#") character and terminated by the end of the URI.
]]

Without the #tag, mailto:  URIs refer to mailboxes, and http: uris 
( other than for special and semi controversion case of 303 redirects ) 
to documents. 

So before anyone panicks at this point, let me stress that this does
not at all mean that we cannot identify people indirectly via email URIs,
or accnt URLs. How does that work? All we need is an inverse functional 
property that ties the object we do have an identifier for ( e.g.. a mailbox ) 
to an Agent/Actor [4]. This is for example what foaf:mbox does, so that we can
indirectly identify me via an email address:

  [] a foaf:Person;
     foaf:mbox <mailto:henry.story@bblfish.net> .

The blank node is the object that refers to me here.

 Of course we may later also discover that I also have a WebID [2]
and so that the following relation holds

 <http://bblfish.net/people/henry/card#me> 
     foaf:mbox <mailto:henry.story@bblfish.net> .

With the right relation we could tie an accnt: URL to a referent of a person
in the same way. Perhaps with

 <http://bblfish.net/people/henry/card#me> 
     foaf:account <accnt:henry.story@bblfish.net> .

If at some point I am playing a role in a virtual game such as 
World of Warcraft ( such as played by 100s of millions of people
around the world ) and I want to have an identifier for a Persona
there, then we can follow Amy's suggestion and create a class of 
Persona [6] 

<http://bblfish.net/personas/Thor#allMighty> a game:Persona;
   game:playedBy <http://bblfish.net/people/henry/card#me> .

or even 

<http://bblfish.net/personas/Thor#allMighty> a game:Persona;
  game:basedOn <http://en.wikipedia.org/wiki/Thor>;
  game:playedBy [ foaf:account <accnt:henry.story@bblfish.net> ] .
 

Authentication and Identity Interoperability
--------------------------------------------

For different types of Identifiers ( WebID, mailto or accnt URI, etc.. ) there 
are  different methods of authentication (and often more than one). With 
mailto URIs one could use Mozilla's Persona to authenticate someone. Or one could
use WebID over TLS [7] to authenicate someone with a WebID. Or indeed using OpenID
would do too.

So if I authentify with my OpenId <http://bblfish.net> ( an indirect identifier )
to a Relying Party then the OpenId has authenticated me indirectly via that 
foaf:openid relation.
 
[]  foaf:openid <http://bblfish.net> .

If the relying party knows the relation

<http://bblfish.net/people/henry/card#me>
    foaf:openid <http://bblfish.net> .

then authenticating with OpenId has also helped identify me with that WebID.

This is what we call Identity Iteroperability and we started doing some
work in this direction in the WebID group
  http://www.w3.org/2005/Incubator/webid/spec/


Web Access Control
------------------

So now back to the access control on resources. We need a follow your nose
approach so that a client on retrieving a URL can know what actors/agents
have what type of access to that resource. With Web Access Control [8] we
have a link from the representation header to a document describing who has
access.

The web acl for a notification container could for example describe the following
access control rules

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

[acl:accessTo <card>; acl:mode acl:Read; acl:agentClass foaf:Agent].
[acl:accessTo <card>; acl:mode acl:Read, acl:Write;  acl:agent <card#i>].


And if <card> contains 

<card#i> foaf:openid </> .

Then the server could offer OpenId to the client (In addition to say WebID over TLS, or WebID
over Mozilla Persona ) when giving him the option to  log in.

Conclusion
----------

I hope that this has shown that there is an easy logial way to get interoperability
between the proponents of different Identity schemes, as well as with different 
authentication schemes, and that we can tie all this nicely into a system for access
control.




[1] https://www.w3.org/wiki/FollowYourNose
[2] http://www.w3.org/2005/Incubator/webid/spec/identity/#overview
  for a longer and more recent video exposition of this see
 https://skillsmatter.com/skillscasts/5960-building-a-secure-distributed-social-web-using-scala-scala-js
[3] https://tools.ietf.org/html/rfc3986#section-3.5
[4] The foaf ontology uses Agent, but Actor will do just as well for this argument
[5] http://xmlns.com/foaf/0.1/mbox
[6] http://lists.w3.org/Archives/Public/public-socialweb/2015Jan/0079.html
    I think it makes sense to have Persona be a subclass of Agent or Actor. After all a 
    Persona in a game is still an actor of that game.
[7] http://www.w3.org/2005/Incubator/webid/spec/tls/
[8] https://www.w3.org/wiki/WebAccessControl

Social Web Architect
http://bblfish.net/