Adventures of an Eternal Optimist

This is a classic. I have to blog it, just to commemorate… this is Fake Steve Jobs accepting a Crunchie award on behalf of the real Steve Jobs at last night’s Crunchie awards… Just wait till you see it… I suggest you not be drinking beverages anywhere near your keyboard while you watch.

TechCrunch, FSJ, you rock my world.

(CAREFUL the language is foul. Don’t play the video if you might get offended)

[youtube=http://www.youtube.com/watch?v=YmfP6aXNSis&rel=1&border=1]

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.

No, really….

Dave, how did you know I’d be interested? :)

I just ordered Garrett, Caleb, and Vittorio’s newly available book on CardSpace from Amazon and I’m eagerly waiting for the deliveryman to make good!

Any book that has a chapter entitled “HTTP and HTTPS: The King is Naked” is guaranteed to be my kind of book :)

Congrats to the authors on being published! I imagine it was a long road.

The first part of 2008 is looking to be a lot of work, but a lot of fun.

My plans until April are as follows:

1. I get to build stuff.
2. I get to (hopefully temporarily) break stuff.
3. I get to write & talk about both.

Stay tuned for more information about what I get to build, what I hope to break, and how I get to blab all about it.

It’s a darn good thing I’m going to have a busy spring, what with the Hollywood writer’s strike and the daft three-ring media circus that will be the 2008 American Presidential Race…  let’s just say it isn’t a good time to be a Canadian couch potato, thank heavens for the CBC’s new winter programming ;)

(today’s Unshelved strip)