RE: ISSUE[UC-5-01:AuthCProtocol]

["Orchard, David" <dorchard@jamcracker.com>]

Hal,

I'd like to try to cast your scenarios in terms of requirements...

1. The AP shall provide attributes about a user to an RP.

2a. The AP shall provide attributes about a user to an RP.  
2aa. The attributes shall include the mechanism of authentication.
2b. The AP shall notify interested parties when a given user logs on.
2c. The AP shall provide user identification information about a user.

3a. The AP shall provide attributes about a user to an RP.
3b. The AP shall respond with the validity of a user's credentials.  
3c. The AP shall respond to a credential validation request from a user.
3d. The AP shall respond to a credential validation request from a RP.  

Do these capture the reqs of your scenarios?  

Cheers,
Dave


> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
> Sent: Monday, February 12, 2001 3:11 PM
> To: 'Mishra, Prateek'; 'security-use@lists.oasis-open.org'
> Subject: RE: ISSUE[UC-5-01:AuthCProtocol]
> 
> 
> Mishra,
>  
> > This is clearly an area of some controversy. First, it is my
> > opinion this issue has nothing to do with [UC-1-04:ARundgrenPush] 
> > so I will not address that issue at all.
> 
> Thanks for the clarification, I agree completely.
> 
> 
> > The exact text of this requirement is taken from S2ML 0.8a, p.7,
> > Section 2.5. The context for this requirement is the following:
> 
> ...
>  
> Ok, let me try to explain this in my own words and see if you 
> agree. I see
> three cases:
> 
> Ignore the issues of push/pull and concentrate on what inputs 
> are provided
> and what is asserted.
> 
> 1. AP says - I know about Joe, here are his attributes.
> 
> 2. AP says - Joe just logged in, here's how you can tell you 
> are talking to
> him, here are his attributes
> 
> 3. RP says - here is some stuff I just got from a user. AP 
> says - that is
> Joe, his authentication succeeded, here are his attributes.
> 
> Case 1 does not involve authentication at all.
> 
> In case 2, the only aspect of authentication that needs to be 
> standardized
> is the codes used to identify the type of authentication done.
> 
> In case 3, we surely will want to limit the number of methods of
> authentication permitted. 
> 
> If my understanding is correct, then it seems the question 
> boils down to the
> one of whether we propose to define an Authentication Service 
> (case 3).
> 
> In my opinion, it will be difficult to accomodate different types of
> authentication methods, e.g. U/P and SSL with client certs, 
> while having the
> AP truely verify the authentication and at the same time 
> using a standard
> browser.
> 
> Hal
>