RE: WebIDauth - authentication service written in PHP.

You made the leap that webid is not about https (only).

If an IDP using some signed token makes assertions about a foaf card (and its identifier), this too is a part of the project. The signed token is playing the role of the client authn signature, in the SSL world. Being a layer 7 token, its not subject to the games that layer client authn signatures have to play. Being a layer 7 token, it is subject to tampering by any web proxy of course. The detection of tampering is not something that this project gets involved in.

Lets say (outside this project), the IDP produces a xml-dsig signed XML blob, in an auto-post. The XML may even use internet and W3C standards (like xml-dsig). And, attached to that signed blob, per xml-dsig, there is another cert chain (of the IDP signer). The SP CAN no do webid validation procedures on that supporting EE certs - to qualify the IDP's signing key.

It can test (i) is the IDP's signing key bound to a foaf card at the webid.IDP, and (ii) is the IDP entitled (under some trust algebra) to make (signed) statements about another webid.User.

I don’t see why the IDP, since its doing dynamic signing, cannot hash the stream it received for the users' foaf card, and include this hash as a claim within its own signed information. Its its willing to validate and rely on that stream, it can re/sign its content. Now one can build an extended validation agent which not only consults the foaf card of the user itself, but also gets an IDP to sign the file for integrity. If (1) the IDP says the file has integrity, and (2) the foaf card received directly by the SP has the same integrity, then one has extended validation. Both sources must be supporting the webid, in this world.

Ideally, there would be metadata that the RP could publish, that tells the world that is uses these procedures when validating. One doesn’t bother communicating with the RP unless the foaf card in question is supported by that set of validation requirements.

Keep doing this, we will eventually re-invent ws-security* of course - except now the metadata will be in RDF rather than XML.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
Sent: Sunday, April 10, 2011 4:34 AM
To: Henry Story
Cc: public-xg-webid@w3.org
Subject: Re: WebIDauth - authentication service written in PHP.

On Sat, 2011-04-09 at 13:09 +0200, Henry Story wrote:
> On 9 Apr 2011, at 12:58, Andrei Sambra wrote:
> 
> > I forgot to mention that I set up a testing suite (more or less), 
> > which can be used to test authentication (either auth.fcns.eu or 
> > foafssl.org), to create foaf profiles in several formats 
> > (json/turtle/rdfxml/n3), lookup webid's and display them in a nice 
> > format / debug format, convert a webid from a format to another (see above).
> > 
> > It's a work in progress so expect lots of things to be bugged.
> > 
> > Here is the link: http://webid.fcns.eu
> 
> yes, that produces very beautiful output.
> 
> But you need a more technical WebID test suite, that will return rdfa 
> describing exactly how the authentication was determined, and showing the user his public key.
> 
> (we have not settled on the rdfa, so for the moment pure human 
> readable html is ok :-)
> 
I see one issue with your suggestion; if a webserver is not configured to request a certificate, it cannot read the public key of the client.
So, we either pass it in the URL from the IdP, or the admin configures SSL on the SP to demand a certificate when connecting to a particular part of the website.

We should also keep in mind that some service providers might not use SSL, but they could verify the validity of the authentication process by checking the signature of the returned URL (webid+ts) and thus allow users to log in with their webids.

> >> 
> > 
> > 
> > 
> 
> Social Web Architect
> http://bblfish.net/
>

Received on Sunday, 10 April 2011 16:15:40 UTC