RE: Updated SSO & Federated Identity use cases

I would not claim that the difference is critical either. 

 

Regards,

 

Yakov Sverdlov

CA

 

________________________________

From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Monday, January 15, 2007 3:37 PM
To: Sverdlov, Yakov; Mary Ellen Zurko
Cc: public-wsc-wg@w3.org
Subject: RE: Updated SSO & Federated Identity use cases

 

The trust relation MUST be between the relying party and the signature
on the card, i.e. the Issuer. When the information is vouched for solely
by the User, we are talking about personalization. The term Security (as
in Web Security Context) does not apply.

 

I still do not see the critical difference.

 

Hal

 

________________________________

From: Sverdlov, Yakov [mailto:Yakov.Sverdlov@ca.com] 
Sent: Monday, January 15, 2007 3:31 PM
To: Mary Ellen Zurko; Hal Lockhart
Cc: public-wsc-wg@w3.org
Subject: RE: Updated SSO & Federated Identity use cases

 

Yes, the identity "cards" may be stored locally and there is a trust
relationship between a card (a certain representation of a digital
identity) and the relying party. The collection of cards represents
multiple and different trust relationships between a user and relying
parties.

 

The user is responsible for picking the appropriate identity when
challenged by a relying party. I agree with Hal that after that the
sequence is very similar to the use cases 1-3 i.e. a token request is
issued to IdP, etc. 

 

I think the following link explains one of the implementations
(CardSpace) better than I do:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/
html/IntroInfoCard.asp
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong
/html/IntroInfoCard.asp> 

 

Regards,

 

Yakov Sverdlov

CA

 

________________________________

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Mary Ellen Zurko
Sent: Monday, January 15, 2007 11:52 AM
To: hlockhar@bea.com
Cc: public-wsc-wg@w3.org
Subject: RE: Updated SSO & Federated Identity use cases

 


Another difference is the authority (the user, vs some third party). 

          Mez

Mary Ellen Zurko, STSM, IBM Lotus CTO Office       (t/l 333-6389)
Lotus/WPLC Security Strategy and Patent Innovation Architect

"Hal Lockhart" <hlockhar@bea.com> 
Sent by: public-wsc-wg-request@w3.org

01/08/2007 10:49 PM

To

"Sverdlov, Yakov" <Yakov.Sverdlov@ca.com>

cc

<public-wsc-wg@w3.org>

Subject

RE: Updated SSO & Federated Identity use cases

 

 

 




I guess I don't get the point of Case 4. There are literally scores of
variations on the cases 1-3 which I did not mention because the details
may or may not matter. Certainly the systems mentioned allow the Subject
Name identifier to be the same. Having them be different is the more
interesting case because:
 
A. It is more general
B. It can preserve privacy.
C. In the real world people actually possess ids with different Subject
Name Identifiers.
 
In your mind what is the critical difference in case for, other than
being yet another data flow?
 
Hal
 

 

________________________________


From: member-wsc-wg-request@w3.org [mailto:member-wsc-wg-request@w3.org]
On Behalf Of Sverdlov, Yakov
Sent: Monday, January 08, 2007 8:49 AM
To: member-wsc-wg@w3.org
Subject: Updated SSO & Federated Identity use cases
 
Hi,
 
I added Identity 2.0 section to the SSO & Federated Identity Wiki page.
After looking at the REST use cases, I don't think they are distinct
enough from the security context perspective, so I didn't add them to
the Wiki.
 
Regards,
 
Yakov Sverdlov
CA