Let’s Make Some Capabilities!!!
All of the OSIS folks have been debating a method for selectors to advertise their supported capabilities to Relying Parties (perhaps with a selector-selector inbetween).
Axel started us off nicely with a proposed string format, HTTP Header name, and syntax (using + to specify explicit support and – to specify explicit lack of support). His example is listed below:
I like Axel’s definition; I’m happy to deal with any format & advertisement method, so to augment this beginning, based on feedback given at an OSIS meeting where a number of people debated this issue, I’m going to propose an initial list of 21 capability identifiers, 16 of which can be rolled up into a bulk identifier called “isip:v1.0” and optionally subtracted from that identifier, and 5 capability identifiers which stand on their own. I’ve based this setup on a few assumptions:
- All capability identifiers are written in lower case.
- I only ever use the “-” sign for subtraction purposes (ie no “-” sign can exist within a capability identifier).
- If duplicates are banned in capability & group identifiers, the capabilities string does not have to be sorted.
- As Dale pointed out in our meeting, once we set the definition of the isip:v1.0 group, we have to stick with it, as we have to have an exact set of subtractable elements to develop to.
- In the case where an identifier (or its group) is not explicitly listed, it should not be assumed that the identifer doesn’t support the capability.
- I have replaced Axel’s “issuerpolicy” capability with the “rpsts” capability; this is because according to this blog post, presence of issuer policy alone is not sufficient to differentiate between a specification of IP/STS and RP/STS (you can specify issuerPolicy if the issuer is an IP/STS, it is just pointless because the endpoint will later be taken from the card itself). Therefore, because issuerpolicy might still signify IP/STS issuer policy and not RP/STS issuer policy, I thought rpsts might be a better choice.
- The “nocassl” capability is dedicated to RL Bob 🙂
- If I’ve interpreted what should be in the isip:v1.0 identifier correctly, CardSpace v1.0 would have this capability string: “isip:v1.0” and CardSpace .NET 3.5 would have this capability string: “isip:v1.0 +nossl” (unless there are more standalone capability identifiers to add for .NET 3.5).
- WS-Trust and WS-SecurityPolicy support capabilities won’t be useful until the self-issued card spec starts to support them, since in the managed card case, the selector just passes that stuff through. As such, perhaps we should leave these identifiers out until they are needed.
My list is below; I recognize it is nothing more than a starting point. I’ve put it into the OSIS Selector Capability Advertisement Wiki Page under “Proposed Capabilities”, which is open for anyone to read & contribute to. As others act to augment, alter, and strike down bits of my initial list, the wiki page will change to hopefully reflect a list that we all can live with.