Defining Meaningful Claims
Convener: Patricia Wiebe
Tags: claims, roles, legal, persona
| Roles: | Claims: | |
|---|---|---|
Employee Legally Designated Professional Dad Husband Hobbyist Alumni Student Citizen |
Domain in bldg D, 4th floor what division level of security | |
"is not" amazon user gmail user |
Claims about Citizens: legal surname legal given names (in BC, 3 legal names are possible) address - mailing, physical delivery, geo location gov't program identifiers, e.g. health #, education # Claims about enterprise users: |
metadata claims: identity provider id level of assurance verification method Should we separate authentication layer from claims layer? openid LiveID |
"Persona": a role a person assumes for a particular context (e.g. acting as a father for some particular purpose, later acting as an employee for another purpose)
Use case: user wants to play a game for a week, they are pseudonymous in the game
Use case: user becomes an avid biker for six months, joins all the forums,
Use case: govt's are already collecting information about users in the form of claims so they can provide appropriate services.
Who do we trust to make claims?
- Avid bicyclist: self-asserted
- More sensitive claims: only from entities who can verify those claims
Trust is important, but it is not a binary value.
There are degrees of trust and assurance.
Trust is not a hierarchy, either. Some claims can only be made by merchant bureaus, other claims can only be made by gov't, other claims are best self-asserted.
Are we conflating the policies around claims with the authentication technologies used?
Yes, for practical reasons claims tend to be made by particular identity providers, so policies and authentication technology get intertwined.
Username/Account is one type of claim, typically verified with a password.
Liberty Project has a concept of identity provider separate from attribute provider.
Use case: one university asserts username and role to another university (probably with Shibboleth). Second university makes an access control decision based on that role. How do we pass those roles around?
Use case: bank allows a user to view their account based on username and password, but wants additional authentication before allowing money to be transferred.
Do we need to add a third "outcome" dimension: (roles or claims) + (action) = outcome
Example: porn site needs to know that user is of legal age in certain jurisdiction
But legal age is not absolute, it varies from jurisdiction to jurisdiction, and for different actions. (For example, legal age for drinking is different from one country to another.)
Assertion: as soon as you talk about assurance and claims, you are also talking about liability.
Concordia discussion group has had long discussions with application owners about what barriers there are to accepting claims from remote parties. This started as a discussion about authentication level of assurance, but moved to attribute level of assurance.
See also:
- Tao of Attributes
- identityschemas.org
- previous discussions at various IIWs.
Reuse of schemas is *hard*. This creates a tower of babel, with different environments creating competing schemas that all look very similar. US Department of Defense spent months trying to agree on a schema, only got 15 attributes everyone could agree were useful.
Context is another important element in access control:
- authentication (how did they authenticate?)
- claims (what statements about the user are being made?)
- context (what is the current situation? is the user in a secure location? what time is it?)
Another example: physician accessing records from hospital premises has different rights than a physician accessing records from home.
Where does that context come from? Does it become a claim? Or do you do it at the transport layer?
Example: drinking age
- If IdP asserts date of birth, there is potential for confusion. Should permission to drink be based on jurisdiction of bar? Or user's jurisdiction?
- Maybe IdP should assert permissions claims "old enough to drink" instead?
- Maybe IdPs should stick to stating facts they can verify (born on this date) and leave interpretation up to IdP.
Example: doctor
- octor might be a radiologist, but that doesn't mean they have permission to view all X-Rays. They also need to be your primary care doctor, or be authorized by the primary care doctor?
Permission claim: implies authorization, transferable from someone with authorization to another person.
Attribute claim: statement of fact about an entity
We have a claims translation problem: it is really bad if N IdPs and M RPs all need to translate claims back and forth. It would be bad if you had N * M explosion in the logic required. Alternative is to have a translation service, where translation service translates N different claim formats to a single format, and from that single format to M RP claim formats.
Assertion: only Permissions claims should cross organizational boundaries. Almost nobody agrees with that assertion.
Counter example: passing around physical location/delivery address does not fit into the "permission claim" model, but is a very common use case.
