Attribute eXchange

OpenID Attribute Exchange v.1.x , 2.0 (2A)

Convener: Nat Sakimura, NRI Notes-taker(s): Tatsuki Sakushima, NRI

Attendees:

• Nat Sakimura (NRI)
• Dick Hardt (Microsoft)
• Henrik Biering (Netamia)
• Mike Hansen (Mozilla)
• Andrew Arnott (Microsoft)
• Will Noris (Internet2)
• Ragavan Srinivasan (Mozilla)
• Breno de Medeiros (Google)
• Ilan Caron (Google)
• Hannes Tschofenig (Nokia Siemens Networks)
• Bharath Kumar (Amazon)
• Tatsuki Sakushima (NRI)

Tags:

• OpenID Attribute Exchange Protocol and Syntax
• Not Schema!

Session Slides: http://docs.google.com/present/view?id=dhsz4ffx_160d4mqqkc3

AX 1.1? and beyond=nat (Nat Sakimura)

Issues raised in AX 1.0

• Introduce the concept of more generic schema for sending/requesting properties about attributes.
  • Class: The new attribute property schemas attach to specific attribute types.
    • Each attribute property schema is bound to a unique attribute-type namespace, can be described by a standard key string (does not need to be defined through a URL value).
  • Query-Response: Attribute property values can be transmitted within any request or response type, allowing communication of attribute properties in both directions in direct and indirect communication request/response pairs.
• Direct Communication: Introduce a direct communication method in both directions (OP<->RP), supported via discovery, for bulk exchange of attributes about (potentially) multiple users.
• Privacy Policy/Sreg features: Update AX to include support for RPs to send a link to their site's privacy policy to the OP. This feature is currently supported in SREG 1.0 and was omitted in AX 1.0.

Approach to solve these issues in AX 1.0

Class

• Now: e.g. 
  • ax.type.fname=http://schemas.openid.net/name/first
  • ax.fname.value=Nat
  • ax.type.lname=http://schemas.openid.net/name/last
  • ax.lname.value=Sakimura
  • etc. 
• New: 
  • ax.type.name=http://schemas.openid.net/opensocial.name
  • ax.name.family_name=Sakimura
  • ax.name.given_name=Nat

Query-Response: Request / Response AX  $ diff openid-attribute-exchange.xml oax1.1.xml  793a794,796 >  <t> > In addition, any parameter values may be sent with the Response as in Fetch Response.  >  </t>

This one line change will allow us to send data to OP and get back the processed data back in the response. 

Or: Parameter to Fetch Request? --> This seems to be better way. 

Direct Communication

• Solved in Artifact Binding
• Privacy Policy URL
• In SREG: openid.sreg.policy_url can be specified in the request. 
• In AX 1.0, it cannot, because you have no way of sending such data in fetch request, nor way to fetch data via Store request. 
• If Store request can also fetch data, the problem is solved: Just the matter of defining standard type URI for privacy policy. 
• i.e., "Bidirectional" solves the problem. 

Next Steps Finish Easy things first, then move onto harder topic. 

AX 1.1

• Add parameter to Fetch Request. 
• Privacy Policy Advertisement

AX 2.0

• More efficient Schema
• Data format: XML or JSON?

Discussion:

• AX Protocol Proposals and Issues from Nat.
• There are lots of interests in “schema” and “schema registory” but not be covered here.
• Make it more generic. 4 areas to improve:

1. Class
2. Query Response
3. Direct Communication
4. Privacy Policy

• Avoid key/value pair(limited capability) and support richer data structures/formats like XML or JSON.
• Also “direct communication” and “different syntax for request and response” are required to make this happen.
• Metadata for attributes like “verified email or just email” → a schema issue? But at least a new format and syntax provide spaces for metadata.
• How to implment a notification service for geolocation in AX? → unsolicited assertion to update_url can be used.
• Is “Privacy Policy” is metadata? → policy_url for Terms of Conditions of Attributes given to RP like Sreg has. The group agreed on this addition to AX.
• Should Policy URL is in a signed request or written in XRD to be fetched from RP? → Artifact binding or Contract Exchange for making a signed request.
• Query Response is used to store and fetch data in the same time. → Need richer syntax for a fetch request.

Next Steps:

1. Class. → Go for it! Support XML, JSON not only a key/value pair.
2. Syntax → Make richer.