IIW-11 Session Presentation November 2-4, 2010

1. OpenID Attributes
beyond AX / SREG
Where should attributes come from ?
How should they be managed ?
Convener: Jay Unger

2. Internet Identity Workshop #11 - Mountain, CA, November 2-4, 2010
Simplicity v. Completeness
Some thoughts on the “tension”
between simplicity and function.
“Everything should be made as simple as
possible, but not simpler.”
Albert Einstein
“Seek simplicity but distrust it”
Alfred North Whitehead
“It’s really hard to design products by
focus groups. A lot of times, people don’t
know what they want until you show it to
them” Steve Jobs
“There aren't any rules around here.
We're trying to accomplish something.”
Thomas Edison

3. Internet Identity Workshop #11 - Mountain, CA, November 2-4, 2010
Simplicity & Good Ideas
“Dr. Pauling, how is it you have so many good ideas?”
Nova Interviewer
“The hard thing is to figure out which ones are the bad ones”
Jay Unger
“The way to get good ideas is to get lots of ideas,
and throw the bad ones away” Linus Pauling
Interview 1977

4. Internet Identity Workshop #11 - Mountain, CA, November 2-4, 2010
Attributes are the only information supplied to
Relying Parties
credentials
Beyond OpenID AX
User
Relying
Party
Identity
Provider
attributes
firewall
user controlled
● Rule 1: Authentication and attribute exchange are entirely separated:
 Authentication information and associated methods are NEVER revealed to
Relying Parties.
 “Strength” and “Assurance” information about authentication means may be
communicated between Identity Providers and Relying parties.
●Rule 2: Attribute exchange is always under control of the user.
 A pseudonym is the only attribute always provided to a Relying Party.
 Users must always be asked to grant permission to as to whether and what
additional attributes are supplied to a Relying Party.

5. Internet Identity Workshop #11 - Mountain, CA, November 2-4, 2010
Attribute Flow and Management
Beyond OpenID AX
User
Relying
Party
Identity
Provider
attributes
user controlled
Attribute
Provider
self asserted
attributes
• All attributes should be digitally
signed
• By their provider
• To insure integrity
• To record provenance
• Attributes should include:
• Assertion (key : value)
• Conditions:
• Duration ( valid / expires )
• Usage Restrictions
• Level / Strength of Assurance
• Dependencies
• On other Attributes (chaining)
• On external information or processes
(vetting)
(SAML XML already has most of this)
•User
• Should be able to control what
attributes are released to which
relying partiers
• Should be able to manage what
attributes are accepted from
Attribute providers.
•Attribute Provider
• Should be able to revoke or modify
attributes that they have provided
to any user.
• User should be informed
Both Users and Relying Parties can
also act as Attribute Providers.
attributes

6. Internet Identity Workshop #11 - Mountain, CA, November 2-4, 2010
Attribute Flow and Management
Beyond OpenID AX
User
Relying
Party
Identity
Provider
attributes
user controlled
Attribute
Provider
self asserted
attributes
• Relying Party
• Ultimately decides what attributes
they believe they can trust
• Based on:
• Identity Provider Trust
• Authentication “strength”
• Attribute Provider Trust
• Attribute details
• Their own policies and
requirements
attributes

7. Internet Identity Workshop #11 - Mountain, CA, November 2-4, 2010
Beyond OpenID AX
● Attribute Expression
● Syntax: Attributes should use the JSON syntax being
proposed for signing and encryption.
● Schema(s)
 Need some sort of extensible mechanism and process for defining,
relating and “transforming” attribute data.
– Referenced like axschema.org (URI)
– Support formatting definition and/or “synonym” and transformation.
– Probably some sort of hierarchical (shallow) namespace.
– Possibly “base” schema (like Portable Contacts) could be a “default” namespace with
minimal syntactic requirements
● Operations:
 “Fetch” and “Store” and possibly “verify” primitives for RPs
 Required and option “fetch” might be composed with authentication
requests as in current AX / SREG.
 RPC-like model could also be supported directly between RPs and
OPs.
Pseudonym should be handled like an attribute but always
returned