[OpenID] cryptographics web of trust

[Story Henry]

This sounds really interesting Peter.

On 22 Aug 2007, at 05:26, Peter Williams wrote:

> Let me simplify all this, by just programming it. I've decide to learn
> the Boo programming language and apply associated Mono compilers (on
> WindowNT).
>
> I will now alter the implementation of the JanRain reference
> implementation of the OpenId Auth protocol handler (written in  
> Boo). The
> OpenID-consumer website leverages this half of the OpenID Auth  
> protocol
> engine, when cooperating with the OpenID server.
>
> Today, that Boo handler gets the user's HTML file; and gets the user's
> XRDS file. Ultimately, it then does a checkid request/response  
> exchange
> with the server, using various bits of metadata from the HTML/XRDS.
>
> For experimental purposes (only), my BOO module will NOT get the HTML,
> and shall NOT get the associated XRDs. It will get metadata from the
> RDF/XML stream from http://peter.com/peter#me. The consumer shall (one
> day) verify the signature on some canonicalized N3-form of this
> resource, having followed a wot authenticating the signer's RSA public
> key.

Ok. So we assume people tell the truth...

> The modified Boo module will now "normalize" using a non-standard  
> rule:
> enter peter.verisign.com in the website login prompt and it will
> normalize this user input as the best practices foafname:
> http://verisign.com/peter#me.

Ok. That reduces your work in changing the consumer, I guess, since  
it gets you right to the foaf file, in that case. The change of  
looking for the foaf link would not be a lot more work, just one more  
download and parsing.

But perhaps the point is here to start from the foaf file.

> The OpenID URI associated with that foafname in the FOAF file at that
> location will be determined by a sparql query against the metadata
> triples. The OpenID resulting from this lookup WILL BE TREATED as a
> "delegate" OpenID for the purposes of OpenID Auth protocol and its
> security procedures.
>
> The location of the OpenID server for the delegate OpenID will be
> determined by querying  metadata for the "service". If there are
> multiple services attached to the claimant's OpenID, Euler-based wot
> path finding logic will select a best.

I suppose here we are back to the usual openid process right? You get  
the openid html file
and search for the links to the openid.server.

Here you are working on Web Of trust of the openid servers?


> The Consumer website will be altered to no longer automatically  
> exploit
> OpenID Ax, upon receipt of CheckID response. It should simply query  
> the
> user's FOAF file for public Person attributes. If one or more
> consumer-required attributes are not present, yet one or more are  
> marked
> as AX-available in the FOAF file, the consumer shall use OpenID AX to
> obtain from the OpenID server "informed-control" rights to receive and
> handle these access-controlled value.

Interesting idea here to specify in the foaf file what types of  
attributes can be found on
the OpenID AX. I wonder how this could be written in foaf... Perhaps  
something like this:


:me a foaf:Person;
     foaf:openid [ = <http://openid.sun.com/bblfish>;
                   openid:server <"https://openid.sun.com/openid/ 
service>;
                 ] .

[] a openId:AttributeExchangeData;
    openid:subject <http://openid.sun.com/bblfish>;
    openid:server <https://openid.sun.com/openid/service>;
    openid:prop <http://example.com/schema/fullname>;
    openid:prop <http://example.com/schema/favourite_movie> .


Do people use foaf urls for identifying relations in the attribute  
exchange? That would make a lot of sense.
It would also be interesting because one could then identify the  
attribute exchange protocol as a form of query. See my recent post  
http://blogs.sun.com/bblfish/entry/sparqling_altavista_the_meaning_of

By the way it is really nice that your RDF tool uses Euler. I wish  
some of the Java ones like Sesame  or Jena used it too. Hope it works  
out.

Let me know where this is going. It certainly may proove to be a very  
good testing ground for new ideas...


Henry





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2429 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070822/9f6af266/attachment-0002.bin>