RE: Input to use case meeting

["Edwards, Nigel" <Nigel_Edwards@hp.com>]

Hi Anders,
I think you have done a reasonable job of describing the messages
that are exchanged, if purple(tm) was used to implement case #1
in the S2ML document. If I understand correctly you are saying
it is possible to build the scenario with less 
pre-configuration than is currently allowed or implied by
the S2ML draft.

Do you have any views on the minimum configuration
requirements that you could articulate to the list?

Thanks and regards,
Nigel.

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Thursday, January 18, 2001 8:39 AM
> To: S2ML-USE; Hal Lockhart
> Subject: Input to use case meeting
> 
> 
> Hi Guys!
> I enrolled the security-service TC as my company is in the 
> process of launching a product
> called Purple(tm) designed for use case #1 (only).  We feel 
> that the input document to the TC
> describes a system that does not lend itself to massive use 
> due to huge requirements
> on pre-configuration between partners.  The following gives a 
> condensed version
> on how our scheme achieves advantages by using 
> challenge-response authentication (and more):
> 
> Purple(tm) in use case #1
> 
> Client clicks on a partner URL on Site A where the client is 
> authenticated
> NEW: Site A challenges Site B at a static URL. Includes a 
> payload as well.
> NEW: Site B responds with a signed payload including a Site A 
> challenge.
> REVISED: Site A creates a signed credential including an 
> arbitrary payload adapted for the partner relation/activity.
> REVISED: Site A pushes the credential if both sites indicated 
> that this was their preference.  Otherwise it must be held in 
> storage a (short) while.
> REVISED: Site A gives the security URL token to the client as 
> a response to the client's request.
> A redirect takes the client to the proper Site B URL where 
> the token is checked and credential is fetched inside or 
> pulled depending
> on already (in-process) settled config data.
> 
> 1. URL/method Config:
> --------------------------
> S2ML v0.8:  2 static URLs + push/pull config.
> Purple(tm): 1 static URL, ZERO push/pull config.
> 
> 2. Trust Config for Site B
> ------------------------------
> S2ML v0.8: Recognize 'n' issuers of signed Entitlements and 
> one(?) issuer of NameAssertions/per partner
> Purple(tm): Recognize ONE issuer of digital credentials/per 
> partner.  Credentials *could* though
>       hold S2ML assertions as payload (if required).
> 
> 3. Encrypted Credentials (option)
> -----------------------------------------
> S2ML v0.8: Will fail every time Site B PKC is renewed. 
> Purple(tm):  Always gets fresh PKC as part of C-R Auth.
> 
> 4. Clock & State Dependencies
> ----------------------------------------
> S2ML v08.a: Not specified. Entitlements have validity but 
> that is not equivalent to authentication time-out.
> Purple(tm): "Ticket" time-out (auth. state-holding 
> requirement) is governed by receiving party (only) although
> Site A could in case of credential pulling indicate a max 
> value it will hold a credential in storage.
> 
> ==============================================================
> ===========
> I suggest that Web-authentication become separate XML objects 
> (and TC task) that *optionally*
> can include S2ML assertions.
> ==============================================================
> ===========
> 
> Regards
> Anders Rundgren
> CTO X-OBI
> 
>