ULX Teleconference 2010-10-04

*Voting members

Quorate meeting 6 of 6

Approved the following minutes:

Signing:

We had a brief discussion of the methods for signing JSON. Consensus was that signing is not important.

Extensibility:

Scott: as long as we come up with a way of people not stepping on each other extensions, then I don't have any concerns with JSON. It looks to me like dotted notation is allowed in JSON, so that makes it easy to do package-type naming. I'm not suggesting that any well-defined fields need to use dotted notation--I'm only suggesting that the extensions do need to use package naming.
Axel: We might need some extensions in the future, but I'd be happy to come up with some simple thing that would be acceptable to 90% of the RPs for the next 5 years. The simplest thing is listing which widely-known IdPs are acceptable for an RP. For example the logical name of the IdP. If you look at the Janrain config files, most things are hidden--all I have to do is give it a list of well-known IdPs and everything else is extra. For example if the user/selector defines a different icon from the one the RP specifies then it should be able to ignore the RP and use it. The most important thing is which IdPs are acceptable, the token format and where to post it. I'd like to make a list of things that are required by an RP and everything else comes later.
Scott: Fine, but extensions are necessary for whatever we do. So as long as we have a standard way of dealing with this, we're fine.
Axel: The problem with dots is that the field names become sub-fields. So if you have dots in the name, then you have dots in the record.
Axel will try a test with dots
Scott: even if it needs to be escaped, that's okay

Format:

Protocol awareness:

Axel: I didn't name (intentionally) anything in here "infocard", etc. For the RP it is irrelevant what the protocol is. The IdP just wants a SAML assertion.
Scott: We need a protocol identifier (OpenID, SAML, Infocard) at the outer "container" level, we can't ignore protocol because in some cases the RP has to initiate the request.
Axel: My impression is that RPs don't accept anything that is much more complicated than un/pw so just listing some well known IdPs might be an 80% solution for most RPs.
Scott: I disagree. We need a solution that works for all RPs.
John: The RPs that are going to put effort into this are going to be worrying about higher levels of assurance
Scott: I'm hoping that most of this complexity will be automated. My assumption is that at a minimum there has to be some protocol awareness so that at a minimum the agent would filter the list of IdPs based on what you know they support.
Consensus: we do want to have the minimum possible in the RP metadata

Content requirements:

The metadata needs to list the ids of the protocol/profiles (e.g. a specific SAML profile) that the RP supports
Need the option for the RP to exhaustively list all IdPs it accepts

Claims:

Paul: I still think that RPs at a high level are interested in claims first and who the IdP is, and tokens very secondarily. I'd like the RP to be able to request claims from N>1 IdPs. I would prefer we not build in the current Infocard limitations.
Axel: We've seen this requirement in the French FC2 projects, and Microsoft is also seeing this need a car-related use case
Scott: Well even if we do support this, we need a way to gracefully fail.
Scott: We should probably include an ability for a claim to list its aliases
Paul: I completely agree. This ability to alias terms (properties, attributes, claims) is the heart of how the Semantic Web's Linked Data really works.
John: I think we need to be able to qualify claims (e.g. as to LOA). And if we're making claims top-level
Scott: I think that value filtering also needs to be supported
John: So claims in our world will be complex
Paul: I've always like the idea of de-referenceable claims
Scott: I think claims should be opaque URIs. Dereferenceability is a SHOULD

Action Items

John to review Inputs to the Selection UI and see if all OpenID requirements are in there