Notes from today's ICF Schemas call

[Paul Trevithick]

Attendees

• Mike Jones
• Ian Hummel
• Paul Trevithick
• Charles Andres
• Drummond Reed
• Uppili Srinivasan
  

DISCUSSION

1. un/pw for managed cards

Paul: where did we get up to on this thread?
Ian: we decided after further discussions that since the use case we had involved a rather tight coupling between the IdP (managed card issuer) and the RP that we should use a private claim values and not ICF-defined claims.

2. Un/pw claims in personal cards

Paul outlined a scenario wherein a browser plugin would form fill un/pw values into an unmodified website having retrieved the un/pw values from a personal card in a selector. Paul outlined one design (A) and Mike mentioned another (B). A good discussion ensued. Rather than repeat the conversation verbatim, I have summarized the two designs here:

Common to A&B

• Note: in the following: ic := http://schemas.informationcard.net/@ics/
• The personal card is an auditing card [enabling the self-issued STS to know the RP’s domain/identity]
• The value of the ic:username claim returned in the token is a single, site-specific value
• The value of the ic:password claim returned in the token is a single, site-specific value
• Both designs can handle multiple un/pw “accounts” at a single site.
  

Design A

• One personal card per relying site [thus a person may well have 50-100 cards]
• Claim types supported on each card:
  
  • ic:username whose value is a [static] string
  • ic:password whose value is a [static] string
  • ic:domain-root/<some-domain> (e.g. ic:/domain-root/amazon.com) <-- this is claim type is present to ensure that the selector only displays the one correct card for the site you’re trying to login to.  
    
• Serialized personal card format:
  
  • Each card would persist the single string values of the ic:domain-root, ic:username, and ic:password claim
    
• STS behavior:
  
  • The STS would only return a token if the RP’s domain matched the domain substring of the ic:domain-root claim.
    

Design B

• One personal card per “role” (or per household member). E.g. a “home” vs. a “work” personal card. Each of these N cards would return a site-specific un/pw [thus a person would have between one and a handful of these cards]
• Claim types supported on each card:
  
  • ic:username [dynamically computed value]
  • ic:password [dynamically computed value]
  • ...the existing 14 well known personal claims...
    
• Serialized personal card format:
  
  • Each card would persist the list of N un/pw values for the N sites for which it could be used
    
• STS behavior:
  
  • The STS would use the RP’s domain as an index into the N un/pw values; it returns the un/pw pair appropriate for the RP site
    

Comparison of A & B:

• Mike felt that B’s smaller number of [cross-site-reusable] cards was a UX improvement over A.
• Paul felt that with appropriate UI treatment in the selector the UX of B could be acceptable. E.g. only cards intended for the RP would be displayed in the selector (usually just one, sometimes 2-3).
• Paul felt that the one-card-per-site approach might be simpler for the average user to understand: In B each card displays the un/pw as simple values whereas in A each card displays only the label “username” --the value, being site-dependent, can’t be displayed.
• B requires an innovation in the card serialization format to handle the N sets of un/pw values. A does not.
• Note: The B design would require human intervention to decide which of N cards should store which un/pw pair in the troublesome case where there are multiple un/pw accounts at a single site. The system would not be able to automatically determine which “role” or “child” card should hold which un/pw pair.
  

--Paul