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

["Mishra, Prateek" <pmishra@netegrity.com>]

Hal,

I agree with your analysis framework but have some issues with your
characterization of Case 2 and 3. 
> 
> 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.
> 

We will also need to characterize various types of credential
produced by the Authentication step. This information corresponds
to the <AuthData> element in S2ML. In other words, there is
more to this step than just saying: the user "authed" with 
a client-cert at the AP. Typically, we want to send the
cert or public key forward within the constructed 
name assertion as well. 

> 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).

I am arguing NOT for the inclusion of an authentication service, 
but for a credential validation service analogous to
S2ML_Auth.

 Lets call it 

              CredsValid: Creds ---> Name Assertion


The model here is that the user has arrived at the RP thru
some means. However, the user is "owned" by a remote AP. The
RP interacts with a credential validation service exposed by
the AP to obtain a name assertion for the user. There may
be many other steps required at the RP (signature checking,
forms of challenge-response, checking MICs etc.). 

I agree with you that giving an exhaustive definition of
Creds is difficult and should not be attempted. However,
user-name password, client certs are an easy starting point.
Notice also, 
that we have very similar issues of Creds characterization for 
Case 2 as well.  


Finally, notice that the interaction here 
is between the AP and the RP, so that browser issues are
not involved at all. The RP can issue cookies or whatever
and the AP has no hand in it. This 
interaction is entirely between the AP and RP.

- prateek
 
> 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
>