Discussing specifically "delegated WebID authentication/identification" - Re: Delegated WebID authentication plugin contributed to fusionforge

Hi.

There has been quite a lot of discussions on "delegating" stuff around
WebID, so I hope we can try and move forward WRT specifying /
standardizing a bit indeed, vs ad-hoc implementations more or less
varying and reimplementing existing wheels ;-)

May I suggest to distinguish this particular case, which I'd call
"delegated WebID authentication/identification" as separate from others for
the clarity of the discussion (the rest being delegated authorization or
likes).


I've added a top-level distinction in
http://www.w3.org/wiki/WebID/Delegation to distinguish between a first
"section" for "Delegated WebID authentication/identification" (proposing
a description based on the current email's case) and letting the rest of
the page the second higher level section, for the previous existing
context.


To make sure that we speak about the same things, "Delegated WebID
authentication/identification" would be the case where WebID profiles
are involved in which the WebIDDelegatedAuth lib (or parts of
libAuthentication, for instance) is used in a web application (which
isn't able itself to prompt user's browsers for their client certs, for
instance) to delegate to a trusted (by the admin of that app) third
party service, which will authenticate the users via their WebID's
client SSL certs, and will in turn provide the requesting app with their
identification in the form of tehir WebID URI. Later, the app may
dereference that URL to fetch additional details about the identified
user in their FOAF.


I think this case is quite similar in many ways to what happens with
using OpenID to delegate authentication to an OpenID identity
provider. The trust relation between the application consuming the
identity and the third party to which it delegates the authentication is
indeed crucial here. There are variants between OpenID and WebID in
where/how the choice of this trust parameters can be defined, but which
may not render implementations so much different for consuming libraries
development (which was my initial concern).

Unless strictly necessary, I think it would be a waste of time to
reinvent parts of the low-level protocol present in OpenID if that can
be reused for the use of WebID (the way to cryptographically sign
responses made by a trusted IdP, security agains replay, etc.). I'm not
speaking about the providing of the attributes which can be fetched from
the FOAF, of course, but more of the API (callback URL, referer and
stuff whose details haven't been specified... and would need to)


Maybe I'm just re-visiting discussions that have happened many times in
the past... and it may just be a matter of spotting the right place in
the wiki where to try and establish a proper wording for this protocol
description, and the READMEs of the various libraries ?


So... what do you think about coining this as "delegated WebID
authentication/identification", and reserving the rest of
http://www.w3.org/wiki/WebID/Delegation more in the frame of "delegated
authorization" ?


I must say I haven't digested all the posts and wiki contents yet, so
appologies if I'm a bit oversimplifying.

Opinions, comments ?

Best regards,

Andrei Sambra <andrei@fcns.eu>
writes:

> Hi Mitko,
>
> On 07/12/2012 11:26 PM, Mitko Iliev wrote:
>>>> 2. Returned URI does not conform to foafssl.org <http://foafssl.org>
>>>> and auth.my-profile.eu <http://auth.my-profile.eu>. These are param
>>>> names retuned by the services mentioned above:
>>>>
>>
>> When this become a standard for params and returned values ?
>
> It was never a standard, it was just the way foafssl.org described an 
> authenticated user, so that libAuthentication could understand. Given 
> that foafssl.org was the first service of this kind, I 
> (auth.my-profile.eu) followed in its steps in order to be compatible 
> with libAuthentication and existing implementations.
>
> We should indeed have a lengthy discussion about the params and returned 
> values (cc Olivier Berger).
>
>>>> a) webid= the urlencoded WebID of the user connecting
>>>>
>>>> b) ts= a timestamp in XML Schema format
>>>>
>>>> c) sig= the signature of the whole URL (signed with the IdP's private
>>>> SSL key).
>>>>
>>>> d) referer= the address of the IdP, which is needed to fetch the
>>>> public key of the IdP's SSL certificate (so the application knows
>>>> from which IDP the signed response comes from in order to choose the
>>>> correct certificate to verify the signature)
>>>>
>>>> More info about the 'protocol' can be found in the README here [0].
>>>>
>>>> [0] https://github.com/WebIDauth/WebIDauth
>>
>> I would be careful to say this is protocol yet ;-)
>> This matter basically should be negotiated and get interoperability
>> testing passed, no way around believe me.
>> So I would expect proposal, call etc. then we can proceed to get it done.
>
> That's why I put protocol between quotes.
>
>> Best Regards,
>> Mitko
>
> Andrei
>
>

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

Received on Monday, 16 July 2012 05:28:26 UTC