[OpenID] openid and acl's

Tue Aug 7 15:41:12 UTC 2007

Let's try that again, typlos removed.

Does this mean, an OpenID server can now be: a "meta-claim" issuing
service?

If the OpenID Server agent issues a set of (signed) claims about #you
(derived from your FOAF file), the relying Consumer agent can reflect
upon the (also) referenced FOAF file for #you directly; and learn that
any signed statement by this particular agent has implicit semantics
that don't require attribute representation in the signed claimset:
group membership(s).

If my OpenID ("http://peter/#me") has a FOAF file for #me (at
"http://peter/") listing several OpenIDs of my several OpenID Provider
agents (each making signed statements), I can implicitly assert group
membership in some, and implicitly assert "cryptographic strength" in
some others. 

In a third set, each agent defines my implicitly represented 
reliance-policy concerning certain other OpenId-identified objects. 

In a fourth set, each agent defines my implicitly represented 
access-policy concerning which other OpenId (or the identified objects,
associated with them rather) have right to edit my HTML and FOAF files.

It's like a fully-inverted ISAM file system, where each column is stored
in an index file, to use a 1960s flashback.

Now, since the reasoning model about FOAF is captured verily in the very
name "FOAF" itself, I can see how hop-by-hop modal logics can be
declared and computed - for any problem domain that needs to compute a
transitive closure function.

By having a generic reasoning engine in the web, any such function can
be defined and deployed, without having to distribute software. The
RDF-based inference model is the software, from which the modal logic
for the problem domain in question is learned.

I think this is ultimately what the ENUM WG in IETF wanted to do, making
the DNS play the role of the semantic web, and a DNS name plays the role
of http://peter/#me.

What's nice about the web approach is that its decentralized, and
disconnected (speaking now, as Peter the security person, who has to
ensure the tank's control system can still compute offline that it is
authorized to fire its nuclear shell, even during radio silence). DNS
can go away, and one can still compute. DNS is just an optional artifact
of http URLs, not necessary for computation. IP address are similar
artifacts. An IPX address in yet another HTTP artifact, as is
cert-metadata in the HTTPS variant.

Ok. I think we have here what SPKI WG in IETF was trying to do 5 years
ago, without having to use Rivest's particular standard logic.

Back to my statement of yesterday. If we dump from HTTPS certs all
naming
attributes, and just have the
"extendedSubjectName={URI}http://peter/#me", the cert in https becomes
pure metadata, enhancing the semantic web as-is.

If we step forward into the future, TLS/SSL v.next actually allows
non-X.509 cert streams in the SSL handshake. One could dump the 1986-era
cert format as we know it, and just use a signed RDF to perform the same
role. Better than signed-XML, the RDF can participate in the evaluation
function(s).

-----Original Message-----
From: Story Henry [mailto:henry.story at bblfish.net] 
Sent: Tuesday, August 07, 2007 2:47 AM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] openid and acl's

On 4 Aug 2007, at 19:30, Peter Williams wrote:

>
>
> 		In "A Foaf File for Sun" [1] I argue that the
Authorization service
> 		can be thought of as a group identifier. The
Authorization service 
> is
> 		a group membership verifier.
> 		
> 		This can be used to give people access to different
parts of the web
> 		using RDF. An example I give is how this could be used
to make 
> access
> 		to the W3C just a question sending someone Sun's foaf
file.
> 		
> 		
> 		Henry
> 		
> 		[1]
http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun
> <http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun>

Just to be critical of my own proposal first.

Whilst using the Authorization service as a group identifier makes
sense, it can be criticized for not scaling in the right way. If every
group tried to have an authorization server then one would be back to
square one, namely having to remember one password per group.  
Well at least one would only need to remember on openid, this openid
pointing to each of the authorisation servers.

Perhaps the idea of having a number of authorization servers can be made
to make sense. If the OpenId had a foaf representation then it could
express which authorisation servers  we linked to which groups.  
My foaf file could be written like this:

@prefix oid: <http://openid.org/tmp/ont#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<me> a foaf:Person;
      foaf:firstName "Henry";
      foaf:family_name "Story";
      foaf:mbox <mailto:henry.story at bblfish.net>;
      foaf:openid [ = <http://openid.sun.com/bblfish>;
                    oid:service [ = <https://openid.sun.com/openid/ 
service>;
                                   is oid:memberIdService of <http://
sun.com/data#sunw> ],
                                [ = <https://openid.sun.com/openid/
engineer/Service;
                                   is oid:memberIdService of <http://
sun.com/data#engineer> ] .

This is saying in short that my openid has two services, one of them
shows that I am a member  of Sun Microsystems, the other that I am
member of the sun engineering team. One could imagine that both of those
use the same authentication password, so as not to be so troublesome.

As the above is a little complex, (I am using the inverse relation of
oid:memberIdService for example), here is the same thing  illustrated
graphically:

_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general