Page Comparison

...

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 defines a different icon....@@@@ . 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

Versions Compared