[foaf-dev] [foaf-protocols] rdfa and openid4.me
akkiehossain at googlemail.com
Sat Mar 6 22:52:45 CET 2010
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
On my "personal" site http://akbarhossain.com I have the above plus a
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.
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
> That *ought* to be enough for openid4.me to work with. Does it?
> Toby A Inkster
> <mailto:mail at tobyinkster.co.uk>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-dev