[OpenID] cryptographics web of trust

[Peter Williams]

What a fun road this has been to travel! 

 

If I hadn't mouthed off about #fragments, I would never have got to see
so much fun stuff! 

 

I can see an interaction of (a) RDF/FOAF's rigorous handling of
URI-based identity (b) openid's classical use case of
webSSO/registrationwizard, and (c) https/certs profiled for URIs. That
intersection is full of possibilities for a secure SemWeb.

 

Don't spent more than 2 minutes! What follows is only partially
organized.

 

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

Most if not all of my own questions in
http://yorkporc.spaces.live.com/blog/cns!5061D4609325B60!228.entry  seem
to be answered by thinking just a little more along the lines of
http://www.w3.org/TR/rdf-sparql-query/#restrictInQuery (once you
substitute foaf:openid for foaf:mbox)

-          We know that such a query can be stored in an Agent's PPD in
some term, encoded in an http URL's querystring 

-          We know that the PPD can be extended by anyone, declaring a
custom class containing several "terms" of type "virtual function"

-          An OpenID namespace extension (e.g. sreg) can have as its
defining URI a live URL pointer to the RDF class definition, allowing an
openid protocol engine to reflect and generically enforce the associated
schema(s) of message extensions

-          The virtual function names can serve as the wire-form names
used for openid named extension fields (ns.sreg.firstname)

-          If the PPD class has such a vfn name that actually has a
function value, at run time the protocol engine can be calling it
enforce one or other runtime access control model ... at a per-attribute
granularity 

-          The access control function can be leveraging XACML's  PAPs,
PEPs, PDPs, etc

But I also see how the same query addresses your wot ideas (where you
endorse a friends key by storing a copy on your server - for others to
recover and now rely on henry's confidence level ...in that key's
authenticity)

-          That query shows how, when recovering nicknames, one get to
distinguish the source of a nickname, and control whether one uses the
master or slave copy. One can treat wot:pubkeyAddress similarly.

-          Reversing the logic, presumably a publicly usable
encoded-SPARQL query stored in Henrys card can be executed by anyone
against the card (where the card is also its own SPARQL Agent endpoint)
...and it will recover Henry's endorsed copy of his friend's pubkeys

-          If the entire interaction is over SSL, with Henry's Apache
server as the https responder, the SPARQL resultset in rdf+xml will be
an assertion that is authenticated by the bearer channel (SSL record
layer assurances)

I just wish one could make SPARQL recursive!

-          It would be fun if, as in my hackedup version of the query
<http://www.w3.org/TR/rdf-sparql-query/#restrictInQuery> , one could
somehow within the query language substitute ?ppd into the named graph
set, recursing/iterating to perform tree/web walking until one hits some
nominated target openid/PPDURI: e.g.  http://example.org/foaf/bobFoaf

-          SELECT ?openid ?pkaorig ?pkacopy ?ppd

-          FROM NAMED <http://example.org/foaf/aliceFoaf>

-          FROM NAMED <http://example.org/foaf/bobFoaf>

-          "  FROM NAMED ?ppd   "

-          WHERE

-          {

-            GRAPH data:aliceFoaf

-            {

-              ?alice foaf:made #me ;

-                     foaf:knows ?whom .

-              ?whom  foaf:openid ?openid ;

-                     wot:pubKeyAddress ?pkacopy ;

-                     rdfs:seeAlso ?ppd .

-              ?ppd  a foaf:PersonalProfileDocument .

-            } .

-            GRAPH ?ppd

-            {

-                ?w foaf:openid ?openid;

-                   wot:pubKeyAddress ?pkaorig

-            }

-          }

-
http://www.intellidimension.com/default.rsp?topic=/pages/rdfgateway/dev-
guide/package/db.rsp shows how to make some templated queries that are
kind of what I'm after  - using that vendors proprietary (but excellent)
approach.

-          If we are setting standards, presumably we would need to be
making SPARQL templates - that to do the same kind of thing. 

If we want to be really RDFish, an OpenID extension (that is defined in
an OWL class) can have a named attribute that is populated by the
consumer. The consumer can put the encoded SPARQL query into the checkid
request, in the form of SPARQL's HTTP-binding URL.

 

-          From the class, the receiving engine can know this is a query
rather than a normal URI ref - and request have some SPARQL server that
it chooses to perform the given query when satisfying the AX request.

 

-          E.g. openid.ns.peterextension.queryme = #?query=<URLencoded
SPARQL query>&named-graph=<targetURI>

 

The nice thing about all of this, is it all applies to SAML2 just as it
applies to OpenID. If, per offline conversations, one just makes the
SAML entityID into a live HTTP URL rather than a URN, and the SSL certs
use the URI nameform option I had ISO add to X.509, there can be
significant interplay between the SAML and OpenID worlds. They will both
be pure URI/IRI identity schemes, over https - where the https certs
bound to the entityIDs are also named using the same URI name form and
URI value.

 

It will be cute to have an IDP issue a signed SAML assertion, bearing an
encoded SPQRQL query that instructs the relying party how to actually
validate the assertion signature-providing the custom query that will
allow that RP to efficiently compute the list of wot:sigEvents that
chain the RP pubkey back to the IDP signing key  - allowing the RP to
rely on the assertion's signature!

                

From: Peter Williams 
Sent: Sunday, September 23, 2007 10:49 AM
To: Story Henry
Cc: OpenID General
Subject: RE: [OpenID] cryptographics web of trust

 

Microsoft tools may be consumer friendly, but they sure make it really
hard work to have folks render on their end what it is that I actually
edit in a simple document editor! Their handling of URLs on cut&paste
into a web email client just seems bizarre!

I posted my last email to
http://yorkporc.spaces.live.com/blog/cns!5061D4609325B60!228.entry.  

It seems to render fine there, at least when using IE7. 

It may be easier to read there.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070924/05773407/attachment-0002.htm>