Input to use case meeting

[Anders Rundgren <anders.rundgren@telia.com>]

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