Notes from today's call (Feb 2)

[Paul Trevithick]

Attendees

• John Bradley
• Ian Hummel
• Charles Andres
• Paul Trevithick
• Uppili Srinivasan
  

1.  UN/PW Claims

• IH: The use case we presented was to allow a legacy application to (through a proxy) present un/pw claims to a RP. There are lots of legacy applications out there that aren’t going to support i-cards
• JB: these are not generic claims. Here’s the question: are you creating a particular card for a particular site? Or are we creating a generic password card that could generate passwords from a generic information card password
• IH: one is a special case of the other. In the former case the IdP/STS only accepts requests from a specific RP.
• PT: are we talking about self-issued cards?
• JB: No Ian is talking about managed cards
• JB: The question is whether these cards would be used in an interoperable way. If you have a private relationship between an RP and one specific STS and no other STS could ever satisfy it then using an ICF-defined claim seems counter-intuitive
• IH: the RP isn’t the “end point” --the RP is really a proxy that converts the token into a post of the un/pw
• US: if you look at enterprise SSO systems. These ARE about capturing and storing credentials from legacy systems and playing them transparently. We do have a use case for a “wallet” to be managed.
• JB: there is a security problem with doing this with self-issued card. The advantage of using an audience-restricted (auditing mode) m-card is that the STS will only hand out the un/pw combination to the site that should get it.
• JB: what we really want is an r-card (the user can edit/update the un/pw)
• JB: if it’s an audience-restricted card then the STS will encrypt the token with the public key of the target relying party
• JB: So my position is that if there are ICF-defined un/pw claims then it should be used with an auditing managed card.
• IH: If I’m the RP proxy, I don’t care who issued the card.
• JB: The question is do you have any trust mechanism around this card.
• US: Assuming that the proxy is a proxy to a legacy RP, while it is true that the RP doesn’t care, the proxy should card (from a security POV)
• US: I suggest: Any STS can choose to assert managed attributes and its meaning can be defined by a proxy. The question is are we trying to define a framework for this. This use case is about securely managing credentials and giving them to proxies. We could frame this as two different cases (i) local and (ii) remote wallets.
• PT: If you look at the scope of this WG narrowly, all we have to do is agree that the proposed claim(s) are well defined and non-duplicative. We’re not supposed to be arguing goodness.
• JB: Yes but we have another criterion “are the claims generally useful—that is, are they defined in an interoperable way.
• PT: Yes, that’s fair
• US: Why is it hard to have audience restriction for self-issued cards?
• PT: Great point.
• JB: It isn’t prohibited by ISIP/IMI
• US: In this WG we can’t avoid having to frame them in the context of some system dependencies. We need to describe a framework for using them.
• PT: You’re probably right.