[foaf-dev] [foaf-protocols] rdfa and openid4.me

Akbar Hossain akkiehossain at googlemail.com
Sat Mar 6 22:52:45 CET 2010


Hi,

I believe this now works.

"So with RDFa, the FOAF+SSL+OpenID setup becomes easy. Create a profile
 web page using RDFa, taking a fragment identifier like "#me" to be your
 WebID; mark up your RSA key using RDFa; include the triple:

       <span about="#me" rel="foaf:openid" resource=""></span>

Then include the openid.server/openid2.provider links in the document
head.
"

On my "personal" site http://akbarhossain.com I have the above plus a
PersonalProfileDocument.

http://www.w3.org/2007/08/pyRdfa/extract?uri=http%3A%2F%2Fakbarhossain.com&format=pretty-xml&warnings=false&parser=lax&space-preserve=true&submit=Go!&text=

I have a certificate with a SAN or http://akbarhossain.com/#me
I also have a cerificate with a SAN of http://foaf.me/ah1#me

I can use either certificate to assert my OpenID http:/akbarhossain.com
As I have the FOAF discovery link  as well.

Thanks


On Sat, Mar 6, 2010 at 7:06 PM, Toby Inkster <tai at g5n.co.uk> wrote:

> In the FOAF+SSL+OpenID setup, there are three URIs involved:
>
> 1. The person's WebID;
> 2. The person's FOAF; and
> 3. The person's OpenID.
>
> In terms of semantics, #1 and #2 must differ, because a FOAF file is a
> foaf:Document, a person is a foaf:Person and those two classes are
> logically disjoint classes (tattoos notwithstanding). (Technically,
> using the same URI for each shouldn't cause any bugs in FOAF+SSL
> implementations, but it's nice to be semantically correct.)
>
> So, assuming that #1 and #2 are different, for FOAF+SSL implementations
> to be able to find #2 given #1, one of the following must be true:
>
>        * The WebID URI redirects to the FOAF URI (HTTP 303); or
>        * The WebID is a fragment identifier added to the FOAF URI.
>
> #2 includes a foaf:primaryTopic predicate pointing to #1. So, all in
> all, #1 can be found if you have #2, and vice versa. If you trust one,
> you trust the other.
>
> Now, as above, #1 and #3 should be different URIs. #1 is a foaf:Person;
> #3 is a foaf:Document. #3 can be found from #1/#2 by following the
> foaf:openid predicate. For full trust to be afforded to #3, it must also
> link back to the FOAF file via rel="meta". The circle is complete. (Or
> the triangle, perhaps.)
>
> We've stated that #1 and #2 must be different URIs; and number #1 and #3
> as well; but, given that we can encode RDF in HTML, there's nothing to
> prevent #2 and #3 from being the same document with the same URI. (Even
> if we couldn't encode RDF in HTML, we could use content negotiation to
> do so, but that seems a little icky as the two things being negotiated
> would not be merely different representations of the same resource -
> they'd arguably be different resources, deserving separate URIs.)
>
> If #2 and #3 are the same URI, then the need for the document to have a
> rel="meta" link to itself disappears. If you trust #2 (which you do if
> you trust #1), then you can't help but trust #3.
>
> So with RDFa, the FOAF+SSL+OpenID setup becomes easy. Create a profile
> web page using RDFa, taking a fragment identifier like "#me" to be your
> WebID; mark up your RSA key using RDFa; include the triple:
>
>        <span about="#me" rel="foaf:openid" resource=""></span>
>
> Then include the openid.server/openid2.provider links in the document
> head.
>
> That *ought* to be enough for openid4.me to work with. Does it?
>
> --
> Toby A Inkster
> <mailto:mail at tobyinkster.co.uk>
> <http://tobyinkster.co.uk>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-dev/attachments/20100306/c9e2770e/attachment.htm 


More information about the foaf-dev mailing list