[foaf-protocols] FOAF+SSL delegation: logging in to an HTTP server

[Melvin Carvalho]

On Wed, Mar 18, 2009 at 2:41 AM, Bruno Harbulot
<Bruno.Harbulot at manchester.ac.uk> wrote:
> Hi Melvin,
>
> Melvin Carvalho wrote:
>>
>> Hi All
>>
>> This has been discussed before but I wanted to suggest a simple
>> solution for the following use case:
>>
>> Use Case: A FOAF+SSL enabled browser wants to log in to an HTTP server
>
> I'm not sure who's key is which in the example.

Thanks for looking at this.  Sorry, I should have been clearer as to
which key/WebID belongs to whom.  I'll try and clarify and have put a
summary at the end.

>
> Let's call the User <https://user.example.net/#me> who has photos on the
> Service Provider (SP) <https://photos.example.net/#sp> and who wants to
> print them using the Consumer <https://printer.example.org/#c> (to make an
> analogy with the OAuth examples.)

This is just a login example, nothing as complex as OAuth.  The
principle is that the Consumer is a low tech server with no access to
https, and wishes to delegate the FOAF+SSL authentication to a
(trusted) 3rd party, the Service Provider, in order to find out the
WebID of the User, and whether it is authentic.

>
>> Solution 1:
>>
>> 1. Consumer redirects User Agent to a FOAF+SSL service provider with
>> known public key
>
> Whose public key is known?

The Service Provider's key is public and previously known (to the consumer).

> If the User connects to the Consumer, which thus knows the User's public
> key. The consumer may also redirect the User to the SP, thus the SP will get
> the User's key.
> Are you involving either of the SP or the Consumer's keys?

At this stage no keys are involved, we simply redirect the User to the
FOAF+SSL Authenticator (Service Provider).  Rewriting (1).

1. The Consumer (which is not HTTPS enabled) redirects the User Agent
to a (trusted) FOAF+SSL Authentication Service.  The public key of the
Service Provider is previously known to the Consumer.

>
>
>> 2. User authenticates, and service provider signs the webid with
>> private key, redirecting User Agent back
>
> Whose WebID? The User's, the Consumer's?

The Users's WebID.

>
> When the user is connected to the SP, the SP can indeed sign something
> (let's call this an "access token") to delegate the user authentication; the
> SP will be able to verify this access token later when it's sent by the
> Consumer.
> The problem is to get that access token to the Consumer.
> It could go back somehow via the browser (Cookies, JavaScript onLoad POST
> redirects a la Shibboleth, ...), or it could be sent directly from the SP to
> the Consumer (assuming the Consumer's WebID was sent to the SP during the
> redirection).

Good point, need to explore this further.  Can the Service Provider
perhaps redirect the User and pass in a query string parameter?
Rewriting (2):

2. The User authenticates with the Service Provider via FOAF+SSL and
at this stage the User's WebID becomes known to the Service Provider.
The Service Provider then uses it's private key to sign the User's
WebID, which it then passes in a parameter, while redirecting the User
back to the original Consumer.

>
>
>> 3. Consumer decodes with public key authenticates as webid
>
> The Consumer doesn't really need to verify the token it has (somehow)
> obtained from the SP (we could add some encryption, but let's assume the
> tokens are in clear at the moment).
> It needs to send this access token when connecting directly to the SP; the
> SP will then be verifying it signed that access token itself earlier (when
> the User instructed it to do so in step 2).
>
>
> In all this, I'm not sure where the OAuth equivalent of the request token is
> (to know what the Consumer wants to access in the SP, for example just the
> conference pictures, but not the party in the pub afterwards...).

This is more OpenID than OAuth.  Rewriting (3)

3. The Consumer decodes the encrypted WebID, belonging to the User,
using the Service Provider's public key.  This enables the Consumer to
know the WebID of the User, and that it was authenticated via a
(trusted) 3rd party.  The Consumer now knows the Users's WebID and can
safely log the User in.

>
>
> Could you clarify which keys and WebIDs are used (User, Consumer, Service
> Provider)? Perhaps I've missed something, but I don't follow the example.

In Summary:

1. The Consumer (which is not HTTPS enabled) redirects the User Agent
to a (trusted) FOAF+SSL authentication service.  The public key of the
Service Provider is previously known to the Consumer.

2. The User authenticates with the Service Provider via FOAF+SSL and
at this stage the User's WebID becomes known to the Service Provider.
The Service Provider then uses its private key to sign the User's
WebID, which it then passes in a parameter, while redirecting the User
back to the original Consumer.

3. The Consumer decodes the encrypted WebID, belonging to the User,
using the Service Provider's public key.  This enables the Consumer to
know the WebID of the User, and that it was authenticated via a
(trusted) 3rd party.  The Consumer now knows the Users's WebID and can
safely log the User in.

>
>
> Best wishes,
>
> Bruno.
>
>
>