[OpenID] cryptographics web of trust

[Peter Williams]

Concerning (A) AX property identities and (B) applying Az policies to
the flow of and encoding of attributes across OpenID AX:-

 

1.  The Openid:prop for fullname could need to be associated with the
names/types/ids of the equivalent properties denoted using
schemas.xmlsoap.org/ws/2005/05/identity.

 

2.  We have to remember that the OpenID AX server responds to attribute
requests, using ultimately some local means to find values (e.g. a
spaqrql query). This pattern is similar to that used in an OpenID
checkID request - which depends on some local means to
authenticate/prove a fullnamed Person's presence.

 

3.  If the consumer & OpenID-server opt to use FOAF-based metadata
(applying the explicit, open-payload architecture of the AX model) to
orchestrate their mutual handling of AX attributes, yet the
"locally-defined" AX value-resolver at some server is using another
vocabulary (e.g. cardspace claims), what do we do?

 

*         If the foaf AX property now declares it association with the
(cardspace) claim it associates with, the user's FOAF file can help
gateway between the AX server and the cardspace token claim-values that
may infact be the (local) source of the AX values.

 

*         The FOAF-based access control policy will still constrain the
AX responder. Those FOAF attributes (typed in FOAF-space) that are
public info from the FOAF file get auto-mapped into the AX response.
Those others FOAF-space attributes must come from some local query, per
the access control policy, use the "attribute-type mapping" to get the
string value... 

 

*         Before the value is delivered to AX to send, any further
access controls are applied (e.g. per-attribute encryption) per
additional policy instructions in the user's FOAF file.

 

 

FOAF will be allowing OpenID to do much of what SAML2 can do in the same
area, when handling attributes, access controls and encrypting
particular attributes. The benefit is... FOAF makes it UCI  managed,
rather than a B2B TTP-only management regime.

 

 

-----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

 

 

 

 

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

 

 

 

The Openid:prop for fullname could need to be associated with the
names/types/ids of the same properties - as expressed in terms of
schemas.xmlsoap.org/ws/2005/05/identity.

 

We have to remember that the OpenID AX server responds to attribute
requests, using ultimately some local means to find values (e.g. a
spaqrql query). This is similar to the patter used in an OpenID checkID
request - which depends on some local means to authenticate/prove the
Person's presence.

 

If the consumer & server opt to use FOAF-based metadata to orchestrate
their handling of AX attributes, yet  the local value-resolver is using
another vocabulary (e.g. cardspace claims), what do we do?

 

If the foaf AX property is declaring with cardspace claim its associated
with, the users FOAF file can help gateway AX to the cardspace tokens
that may infact be the source of the values.

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