Shibboleth Developers

[Peter Williams <>]

Hmm.

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.

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).

How is the cardspace + Shib design conceived? 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)?

________________________________________
From: Scott Cantor 
[]
Sent: Monday, June 09, 2008 12:41 PM
To: 

Subject: [Shib-Dev] Re: SHIB Status call -- 6/9/2008)  -- 12:00 pm EDT, 9 am 
PDT

> if you get an account at myopenid.com you will see a GUI
> allowing individuals to set release policies for their
> attributes, upon websso. As a site is encountered, the user
> nominates the set of attributes to be released (this time,
> always, never). One can change the policy also, using the
> management console.

Leaving aside that this still lacks any compelling proof of user acceptance, 
there's clearly (to me) a big difference between a page for managing 
"well-known" profileish attributes like one would see in a vcard, and the 
more complex attributes used for authorization, specific to higher ed (or 
other sectors), and complex identifiers with different privacy properties.

In other words, I don't think any GUI has to be generic to be useful, nor do 
I think a generic one will be useful. We have to get over the "all or 
nothing" approach to this to make progress.

-- Scott