OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-use message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC