[wsf-dev] OpenID Bootstrapping into ID-WSF

[Asa Hardcastle]

Thanks for the notes George, and I'm sorry you won't be joining us on  
the call.  As long as you have an appropriate DS-EPR it will be  
easily  possible to bootstrap to ID-WSF (from the WSC perspective  
that is).   So in this case trust would be established by OpenID  
SSO?  And please forgive my OpenID ignorance, this is a centralized  
process, right?

asa




--
Asa Hardcastle, Technical Lead, openLiberty
Tel: +1.413.429.1044 Skype: subsystem7



On May 2, 2007, at 11:10 AM, George Fletcher wrote:

> Unfortunately I have a conflict this week at 11am ET so I won't be  
> able to join the call.
> I've attached my notes from one of the sessions (led by Paul) that  
> addressed how this might work.  However, I'm not sure it impacts  
> the WSC code significantly.  It really addresses what the site  
> needs to do to get the necessary "bits" to invoke the WSC library.   
> This goes along with what Scott was talking about in the last  
> call... being able to provided the necessary "bits" to bootstrap  
> the process.  So some potentially some library call that allows the  
> invoker to pass in a DS-EPR and optionally a security token to use  
> with that DS-EPR (provided the DS-EPR doesn't contain the necessary  
> security token).
>
> Thanks,
> George

> Title:  IOS -- Brussels -- Identity Meta-System "Slice & Dice"
>
> Date:  April 27, 2007 8:33 AM
>
> Category:  Identity
>
> Tags:  Identity Meta-System
>
>
>
> Existing Identity Systems
>
> -- OpenID
>
> -- SAML
>
> -- Cardspace
>
> -- WS-Federation
>
> -- ID-WSF
>
>
>
> Parts of an identity-based experience online
>
> -- Authentication
>
> -- Single-Sign-On / Single-Log-Off
>
> -- Front “channel” Attribute Exchange
>
> -- Back “channel” Attribute Exchange
>
> ** Discovery and Authorization can occur between steps
>
>
>
>
>
> OpenID
>
> SAML
>
> Cardspace
>
> WS-Federation
>
> ID-WSF
>
> Authentication
>
>
>
>
>
> X
>
>
>
> X
>
> Single-Sign-On
>
> X
>
> X
>
> X (1)
>
> X
>
> X
>
> Single-Log-Off
>
>
>
> X
>
>
>
> X
>
> X
>
> Front Attribute
>
> X
>
> X
>
> X
>
> X
>
> X (2)
>
> Back Attribute
>
> X (3)
>
> X
>
> X
>
> X
>
> X
>
>
>
> (1) The user has to select the card for each web site so while not  
> require the user to enter their password to access multiple steps,  
> the user is NOT automatically signed in to multiple sites
>
> (2) While possible this is not what ID-WSF was designed for and  
> it's stretching the definition a bit
>
> (3) OpenID does not support protected back channel attribute  
> exchange.  So if there is public identity data that any one can get  
> without authentication, then it's possible to do this with OpenID.   
> Of course, you could get this data without doing any OpenID operation.
>
>
>
> Possible Bootstrapping paths through this matrix
>
> 1. OpenID authentication bootstrapping to ID-WSF back channel
>
> -- key piece of data is the DS-EPR
>
> -- could be returned in the authentication step as another form  
> post element that is signed
>
> -- what is returned could be the full DS-EPR or an artifact for the  
> assertion
>
> -- this method allows the OP to construct the DS-EPR such that it  
> contains all the necessary security information such that the  
> recipient can directly invoked the DS
>
>
>
> 2. Leverage YADIS mechanisms to discover the ID-WSF Discovery (DS)  
> service
>
> -- this DS-EPR would instruct the SP to go get the appropriate  
> security token necessary to invoke the DS
>
> -- this “get the appropriate security token” could leverage WS- 
> Trus, SAML, or OpenID mechanisms
>
> -- all profiles should be defined
>
> -- this means that the location of an individual's DS service is  
> public knowledge
>
> -- in the “normal” ID-WSF model the authentication service returns  
> the DS-EPR ensuring that it is delivered to an agent that has  
> successfully authenticated the user
>
>
>
> 3. Cardspace delivering OpenID and SAML assertions
>
> -- already supports SAML 1.1 assertions
>
> -- needs to allow RP to request the correct kind of assertions
>
> -- OpenID, SAMLv2 with DS-EPR, etc
>
> -- this may be a bigger deployment problem than a technical problem
>
>
>
> 4. Retrieve an individual's DS-EPR via a SAML NameId
>
> -- assuming this is a SAML “profile” or “addition”
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openliberty.org/pipermail/wsf-dev/attachments/20070503/d6abad95/attachment.html