Difference between revisions of "Defining Meaningful Claims"

From IIW
Jump to: navigation, search
(Undo revision 3149 by Igiwydijok (Talk))
 
Line 1: Line 1:
=[http://ezemitekywe.co.cc UNDER COSTRUCTION, PLEASE SEE THIS POST IN RESERVE COPY]=
 
 
'''Convener:''' Patricia Wiebe
 
'''Convener:''' Patricia Wiebe
 
  
 
  
Line 8: Line 7:
 
!'''Roles:''' !!'''Claims:'''
 
!'''Roles:''' !!'''Claims:'''
 
|-
 
|-
|<br> Employee<br> Legally Designated Professional<br> Dad<br> Husband<br> Hobbyist<br> Alumni<br> Student<br> Citizen
+
|<br> Employee<br> Legally Designated Professional<br> Dad<br> Husband<br> Hobbyist<br> Alumni<br> Student<br> Citizen
|&lt;br&gt; Domain&lt;br&gt; in bldg D, 4th floor&lt;br&gt; what division&lt;br&gt; level of security
+
|<br> Domain<br> in bldg D, 4th floor<br> what division<br> level of security
 
|-
 
|-
|&lt;br&gt; &quot;is not&quot;&lt;br&gt; amazon user&lt;br&gt; gmail user
+
|<br> "is not"<br> amazon user<br> gmail user
|'''Claims about Citizens:''' &lt;br&gt; legal surname&lt;br&gt; legal given names  (in BC, 3 legal names are possible)&lt;br&gt; address - mailing, physical delivery, geo location&lt;br&gt; gov't program identifiers, e.g. health #, education #  
+
|'''Claims about Citizens:''' <br> legal surname<br> legal given names  (in BC, 3 legal names are possible)<br> address - mailing, physical delivery, geo location<br> gov't program identifiers, e.g. health #, education #  
  
'''Claims about enterprise users:'''&lt;br&gt; employment type (employee, contractor)&lt;br&gt; position title&lt;br&gt; employment role (manager, director)&lt;br&gt; organization id&lt;br&gt; organization type (gov't, business, corporation, proprietorship)&lt;br&gt; professional role/designation&lt;br&gt; professional body
+
'''Claims about enterprise users:'''<br> employment type (employee, contractor)<br> position title<br> employment role (manager, director)<br> organization id<br> organization type (gov't, business, corporation, proprietorship)<br> professional role/designation<br> professional body
|'''metadata claims:'''&lt;br&gt; identity provider id&lt;br&gt; level of assurance&lt;br&gt; verification method&lt;br&gt;'''Should we separate authentication layer from claims layer?'''&lt;br&gt; openid&lt;br&gt; LiveID
+
|'''metadata claims:'''<br> identity provider id<br> level of assurance<br> verification method<br>'''Should we separate authentication layer from claims layer?'''<br> openid<br> LiveID
 
|}
 
|}
  
'''&quot;Persona&quot;:''' 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)
+
'''"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 wants to play a game for a week, they are pseudonymous in the game
Line 49: Line 48:
 
'''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.
 
'''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 &quot;outcome&quot; dimension: (roles or claims) + (action) = outcome
+
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
 
'''Example:''' porn site needs to know that user is of legal age in certain jurisdiction
Line 80: Line 79:
 
Example: drinking age
 
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?
 
* 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 &quot;old enough to drink&quot; instead?
+
* 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.
 
* Maybe IdPs should stick to stating facts they can verify (born on this date) and leave interpretation up to IdP.
  
Line 96: Line 95:
 
Assertion: only Permissions claims should cross organizational boundaries.  Almost nobody agrees with that assertion.
 
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 &quot;permission claim&quot; model, but is a very common use case.
+
Counter example: passing around physical location/delivery address does not fit into the "permission claim" model, but is a very common use case.

Latest revision as of 11:45, 2 February 2011

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:
employment type (employee, contractor)
position title
employment role (manager, director)
organization id
organization type (gov't, business, corporation, proprietorship)
professional role/designation
professional body

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.