Client requesting authentication on server & thomson-httpbis-catch

["[e-mail]" <[e-mail]>]

Hi,

    We have a problem that is somewhat the opposite of the
one described by Martin Thomson recently under draft-thomson-httpbis-catch-00 [1]
though we could make use of it.

We want to deploy client authentication using TLS now [0], with browsers and clients
as they are - that is we cannot wait for TLS1.3, though we look forward to it and
improvements such as draft-thomson-tls-care [3]

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.

$ 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 do something that it does not have access to. 


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