[wsf-dev] OpenID Bootstrapping into ID-WSF

[Recordon, David]

Hi Asa,
Is this something you envision being discussed at the DC meeting later
this month?
 
Thanks,
--David

________________________________

From: wsf-dev-bounces at openliberty.org
[mailto:wsf-dev-bounces at openliberty.org] On Behalf Of Asa Hardcastle
Sent: Thursday, May 03, 2007 6:00 AM
To: George Fletcher
Cc: wsf-dev at openliberty.org; Brett McDowell
Subject: [wsf-dev] OpenID Bootstrapping into ID-WSF


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/20070514/b086f568/attachment.html