Skip to Content.
Sympa Menu

shibboleth-dev - RE: What will interoperability of Shib with CardSpace encompass?

Subject: Shibboleth Developers

List archive

RE: What will interoperability of Shib with CardSpace encompass?


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: What will interoperability of Shib with CardSpace encompass?
  • Date: Thu, 24 May 2007 14:18:55 -0400
  • Organization: The Ohio State University

> What isn't clear from this (at least to me) is what the scope of this
> collaboration between Microsoft and Internet2 will encompass. Has the
> scope been determined/agreed to?

No. It's a research project.

> - Is it intended to both provide the functionality within the Shib
> IdP to issue a "shib managed card" (and subsequently interact with
> that managed card to get a signed security token) and then to provide
> the functionality within the Shib SP to accept a managed card?

I would assume so.

> - And would the card(s) useable at a Shib SP be identified as "any
> Shib card", or would they be tied to a federation (e.g. "any InCommon
> card")? Or something else?

There is no such things as a federation in the software. Not now, and I
would not expect it here.

> - If the Shib SP is modified to accept a "Shib InfoCard", will it
> also be able to continue to accept the current flows? I.e. would it
> be easy to support both?

Cardspace defines two different general RP flows, one involving an STS at
the RP site, the other is HTTP POST. I don't expect the POST option will be
significantly different from what's there now, and it will probably look a
lot like supporting SAML 1.0, 1.1, 2.0, and ADFS does.

My feelings about APIs and invading applications are well known. If the app
has to do anything to support this that's new, we've failed and the app will
be broken.

> And how does Federation metadata factor into all of this?

Cardspace definitely requires its own security policy metadata and you have
to post it where the client can get it. Not clear yet whether any kind of
linkage to SAML metadata will be possible or useful. Much of its key
management would fall into the category of what I would deem "insufficient",
often times devolving to "hey, tell me your key and I'll use it", with the
goal being minimal confidentiality, not what I feel is strong security.

A lot of the "trust" between sites seems to be punted to this EV certificate
nonsense. I think a lot will be up in the air until that initiative
collapses.

Jim's already been exploring a lot of the different options for how
encryption gets used and what information about the providers is needed.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page