[foaf-protocols] OpenID2 Server: openid4.me

[Akbar Hossain]

Hi Peter,

As always your questions/thoughts are great. My view inline.

On Mon, Nov 2, 2009 at 6:36 PM, Peter Williams <home_pw at msn.com> wrote:

>  * *
>
>
> The FOAF file will need a PersonalProfileDocument with a PrimaryTopic entry
> which matches the URI in the X.509 Client Certificate.
>
>
>  *[Peter Williams] This sounds like the condition the OP will enforce,
> before considering the user authenticated (using foaf+ssl). Only then would
> it considering releasing a positive assertion.*
>
Yes this is what is happening

> *Whether the assertion makes a representation that the openid identity is
> a verified webid – or whether an sreg/ax attribute conveys the same – is a
> detail. Ideally, it will be an attribute, so openid and foaf+ssl stay wholly
> independent (but complementary).*
>
In the current implementation there are no accounts details stored for each
OpenID (local ID) the server encounters.
So the only places to store something is either in the FOAF file (which is
the PersonalProfileDocument and is referred to by the OpenID URI) or on the
URI being used as the OpenID (which is the original implementation or if we
went for the "WEBID" autodiscovery link). If the service made use of another
OP then I guess yes the webid could be sent via AX. I guess in that case
this server would be a RP of another OP server (assuming I have undestood
your comment). BTW. I was looking at myopenid for documentation on the
openid.sreg.web  I couldnt find anything but I will keep looking or program
something to look into it further. I see where I set the attribute in my
profile.


> *Does the condition need to be stronger?*
>
> *Should the OP (when validating the claims and facts from the various
> foaf+ssl principals) consider what data source _domain_ was certified by the
> https channel/cert it uses when _retrieving_ the foaf file’s graph?*
>

Yes this would make sense to me to avoid DNS attacks. I think there was also
some talk about signing the RDF graph to avoid someone changing that too. In
the case of signing the graph I think this is something worth exploring more
I have seen some papers on this. As you mention/suggest the https channel is
likely to require a certificate. I believe this would need to be the
certificate of the service fetching the foaf file. Or would we go for some
sort of oauth (printing service) method of fetching the resource where the
end user permissions the fetch.


> *Take a case that stresses the above question. If the resource server
> providing the foaf file was to do a 302 redirect to the OP pointing at
> another https domain (which does actually deliver the rdf stream), would the
> OP still be willing validated the user as controlling the webid – and thus
> be deemed “authenticated”?*
>
> *Let’s say that after the domain of the streaming server, post 30x
> redirect, no longer matches the domain of the (absolute) URI of the users’s
> personal **profile doc.*
>

In the current implementation no it wouldnt match. I'm not sure it should
match the redirects. I would have thought the URI in the X.509 should match
or you should regenerate the certificate in the case you are moving the your
foaf file around. Ideally the regeneration of the certificate should be
cheap enough and simple enough to do. Not sure what others think.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20091102/32ea5a4a/attachment-0001.htm