| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Logistics
...
- Paul Trevithick *
- Axel Nennker *
- Scott Cantor *
- Keith Uber *
- Benoit Bailleux
- Bob Morgan *
- John Bradley *
*Voting members
Quorate meeting 3 6 of 56
2) Minutes
Approved the following minutes:
...
- Discussion of Axel's email; JSON vs. XML, etc.
- See also Inputs to the Selection UI
Signing:
- We had a brief discussion of the methods for signing JSON. Consensus was that signing is not important.
...
- 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
...
- 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
See also http://kantarainitiative.org/confluence/display/ulx/Inputs+to+the+Selection+UI
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 http://kantarainitiative.org/confluence/display/ulx/Inputs + to + the + Selection + UI and see if all OpenID requirements are in there
...