[OpenID] cryptographics web of trust

Wed Aug 22 18:10:32 UTC 2007

Q1: 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.

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

-------------------------

On Q1:

I am ignoring the HTML file and XRDS file, entirely. Didn't your "foaf
file for sun" blog entry show that 

(a) for any user's OpenID, one can denote in the metadata its "
'affiliated' issuing organization" (e.g. Sun), 

(b) the location of the "issuer's" OpenID Server(s) (for SUN) can be
represented ready for discovery by anyone querying just the FOAF
metadata (and its links) and knowledge of the target OpenID (and/or
foafname) 

(c) the semantics of the OpenID Auth's CheckID response messages
manufactured by particular server at URL A can be indicated in the
metadata?

(c1) server at (SUN) URL X attests to group membership, with
organizational affiliation being the default criteria.

(c2) server at (SUN) URL Y attests to employee vs contractor vs status

(c3) server at (SUN) URL Z attests to Person being subject to unusually
invasive policy rules (mandatory key escrow, records retention) because
their job requires records to ensure one can test in the future for the
absence of certain conflicts of interest?

On Q2:

For now, I have suspended my use of wot graph search for the purposes of
forward and reverse chain building (to properly protect the DH keying
material being distributed as the crypto-base for then creating the
underlying security "association"). I will return to it, once I've
improved it to also use decent key-wrapping techniques per NIST/NSA
guidance. This will bring onboard well-understood control plane
mechanisms, necessary for use of OpenID in critical infrastructure
environments. Cipher independence will also be required, as DH is not
acceptable to many operating environments.

However, I am immediately going to use wot (and Euler based searches) to
PICK between several OpenID severs (with the same semantics). This will
replace what XRDs do today, which uses declarative hints (e.g. 60%, 40%)
attached to each endpoint URL. Rather than such declare constant values,
the wot search will allow the resulting path to deliver a dynamic
confidence rating that is evaluated in part based on (a) hill climbing
(i.e. path bounding) constraints imposed by the querying party, and (b)
the particular semantics being asserted by this set of sever endpoints. 

-----Original Message-----
From: Story Henry [mailto:henry.story at bblfish.net] 
Sent: Wednesday, August 22, 2007 8:08 AM
To: Peter Williams
Cc: OpenID General
Subject: Re: [OpenID] cryptographics web of trust

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