Client ACLs and WebIDs

Hi,

    Here is a subtle issue with authentication, WebID and Web Access Control.


Our problem is that we have resources that can return different information
(header or body) depending on the authentication level. Consider for example just
the Allow: header. If a user is not authenticated we return the methods allowed for
an anonymous user, i.e., he is allowed access to methods OPTIONS, GET, HEAD
as shown here:

$ curl -I -k https://bblfish.stample.io/card
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Allow: OPTIONS, GET, HEAD
Content-Type: text/turtle
Accept-Patch: application/sparql-update
Link: <card.acl>; rel=acl, <http://www.w3.org/ns/ldp#Resource>; rel=type

( Following the acls could let a more intelligent user agent know what rights 
 it may have as different users, but not as current browsers are set up [2] )

A server could use the thomson-httpbis-catch WWW-Authenticate header to let 
the client know that authenticated users could do something more if it 
authenticated. Perhaps like this:

$ curl -I -k https://bblfish.stample.io/card
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Allow: OPTIONS, GET, HEAD
WWW-Authenticate: Certificate
Content-Type: text/turtle
Accept-Patch: application/sparql-update
Link: <card.acl>; rel=acl, <http://www.w3.org/ns/ldp#Resource>; rel=type 

But now how does the client authenticate with TLS in the current browsers?
We don't want the client to do a PUT or a POST or a DELETE on the resource
just to force a TLS renegotiation. That would be danderous.


There seem to be two choices here:

1) to have an authentication header that the client could add,
  to ask the server to authenticate it using TLS client certificates by
  forcing a renegotiation. Perhaps a client could do 

  GET /card HTTP/1.1
  Auth: Certificate
  ...

 This would be the equivalent in HTTP of what Martin Thomson proposed at the TLS
 level in his "Client Authentication Request Extension for (D)TLS" RFC [3] . 


 2) For the server to publish a link relation to a authentication resource.
  Perhaps with a Link: rel=authn

$ curl -I -k https://bblfish.stample.io/card
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Allow: OPTIONS, GET, HEAD
WWW-Authenticate: Certificate
Content-Type: text/turtle
Accept-Patch: application/sparql-update
Link: <card.acl>; rel=acl, <http://www.w3.org/ns/ldp#Resource>; rel=type 
Link: </login>; rel=authn

  Perhaps for TLS renegotiation a more specific rel=authn-tls would 
be useful. (It's not sure if this answer still needs the WWW-Authenticate: Certificate 
header ). 

  A lot of things are moving in HTTP, so I may have missed the right tool 
for the job.

Henry

[0] Using http://www.w3.org/2005/Incubator/webid/spec/ WebID over TLS
[1] http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/
[2]  A client could follow the card.acl resource to find out what it is allowed to
do if it is logged in [2], though this would not be too much help for Web Browsers
as these do not necessarily know what their identities are - they can't for
example access the Certificates in their key store - so the JavaScript would have
difficulty finding out what group it belongs to.  Note: The acl link is defined 
in the Web Access Control page of 
    http://www.w3.org/2005/Incubator/webid/spec/
( it needs to be standardised )
[3] http://datatracker.ietf.org/doc/draft-thomson-tls-care/



Social Web Architect
http://bblfish.net/

Received on Wednesday, 19 March 2014 09:59:40 UTC