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:
version='urn:osis:infocard:2008-04'; name='urn:osis:infocard:names:openinfocard'; capabilities='+nossl+javascript-issuerpolicy'

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:

  1. All capability identifiers are written in lower case.
  2. I only ever use the “-” sign for subtraction purposes (ie no “-” sign can exist within a capability identifier).
  3. If duplicates are banned in capability & group identifiers, the capabilities string does not have to be sorted.
  4. 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.
  5. 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.
  6. 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.
  7. I haven’t added Axel’s “javascript” identifier, because I wasn’t sure how an RP might react differently based on the addition or subtraction of that capability – Axel, please feel free to add it.
  8. The “nocassl” capability is dedicated to RL Bob :)
  9. 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).
  10. 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.

Capability List (image)


4 thoughts on “Let’s Make Some Capabilities!!!

  1. Great work Pamela!

    One possible refinement that might be used in practice is to allow Identity Selectors to declare that they do or don’t support particular kinds of managed card authentication methods.

    I could imagine capabilities like these:
    that together comprise your proposed managedcard identifier.

    Would that make managedcard a subgroup? Do we want nested groups?

  2. I actually had that in there, but took it out before I posted it :) I figured that if the RP knows absolutely for sure that they have to have a certain backing for a card, they must know the issuer too – and if that’s the case, why not just require the issuer…

  3. How about starting with some use cases?

    How about following that up with some requirements?

    Why is is better to handle some of these in an “advertisement string” instead of with a later version of the information card protocols (if it can’t be handled with current protocols)?

    The third and fourth seem especially screwey. If an identity selector can’t do both, then it can’t claim that it does information cards. The last time I checked, doing only one is not an option for identity selectors.

    I do like your response to Mike’s suggestion. I wonder how many other proposed capabilities this argument would apply to.

  4. I have use cases for all of the capabilities Eric – I didn’t include them because they tended to get repetitive, but I certainly can if you are interested. The reason why at I as an RP might want these particular capabilities available to me prior to the invocation of the protocols, is so that I can reduce the number of failed card transactions I trigger. If my RP uses an RP/STS, and I see that the user’s selector advertisement is “isip:v1.0 -rpsts”, I don’t have to send the user on a fool’s errand, I can give them an actionable message. The use case is basically the same for all of the capabilities I’ve listed here (noting that explicit lack of support is by far a better indicator than absence of explicit presence of support). I realize that there will be other uses for these strings, but this is the type of use case that has inspired my first attempt.

    Hope that helps,


Comments are closed.