Shibboleth Developers

["Scott Cantor" <>]

> The GUI concept that myopenid offer is really only a variant of the basic
> GUI model of cardspace: choose the particular (self-issued) card with the
> limited attributes you want to release ... to the particular relying
party.
> Microsoft use a card metaphor for the GUI, myopenid a personality metaphor
> for the GUI.

And Cardspace's self-issued cards only deal with vcard-like attributes,
which is why it's (maybe) workable.

> If there is no compelling proof of user acceptance of myopenid then there
is
> noe either for cardspace. Or, if its accepted as proven for cardspace, its
> therefore accepted as proven for myopenid (using a 3000 year old rule of
> logic).

It's fairly apparent to me that there's no proof of user acceptance of
Cardspace. Not even a vague one, let alone anything compelling.

> How is the cardspace + Shib design conceived?

Essentially, it isn't. Partly I suppose for this exact reason. The SP half
is fairly simple, it's the IdP half that needs thought into what exactly
we're trying to provide.

> Is the cardspace support
> architected as gateway to the IDP (much like an IDP can be a kerberos
ticket
> relying party), or is the SP the peer (as in the ADFS/Shib integration
> model)?

Infocard is just another protocol we would support natively.
 
-- Scott