I think there are subtle differences between authentication method,
authentication context, and what I will call authentication context
policy:
From reading the WS-Policy document, I see that it provides a framework
for expressing policy decisions. So, one might imagine I could
enumerate both the authentication method policy I support as well as
potentially the the authentication context policy I support, using that
framework. This seems similar to the WS-SecurityPolicy document that
describes the interface between WS-Security and WS-Policy.
So, if one of my authentication contexts were MobileTwoFactorContract
authentication, the authentication methods might be
a) presence of SIM
b) entry of PIN
As an authentication authority, my policy might be to offer this
context for my authentications. As a client/relying party of that
authentication authority, I may have the policy that I will accept only
MobileTwoFactorContract authentication (and I may also either care or
not care what the two factors/methods are). Such policies could
presumably be expressed using WS-Policy and by creating extensions for
authentication contexts in a similar fashion to those created for
expressing WS-Security related policies.
- JohnK
On Wednesday, Oct 15, 2003, at 11:09 US/Eastern, Anthony Nadalin wrote:
>
>
>
>
> Well not true, WS-Policy is a framework that can deal with any type of
> assertion that conforms to the grammar defined in WS-Policy, so these
> can
> be assurance or attestations assertions. So my view is that the
> authentication context is really not needed but rather just extend the
> authentication method schema to accommodate.
>
> Anthony Nadalin | work 512.436.9568 | cell 512.289.4122
>
>
> |---------+---------------------------->
> | | <Frederick.Hirsch|
> | | @nokia.com> |
> | | |
> | | 10/15/2003 09:20 |
> | | AM |
> |---------+---------------------------->
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> --|
> |
>
> |
> | To: Anthony Nadalin/Austin/IBM@IBMUS,
> <>
> |
> | cc:
>
> |
> | Subject: RE: [security-services] Groups -
> authentication-context.pdf uploaded
> |
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> --|
>
>
>
>
> Tony
>
> I do not believe that WS-Policy addresses the same issues as the
> authentication context. For example, authentication context can say how
> you've authenticated (or want to) in terms of quality of registration
> and
> so on. Sure, this can be considered "policy" in the abstract, but from
> my
> understanding of WS-Policy, this is not addressed specifically by the
> WS-Policy drafts.
>
> WS-Policy looks like interesting work, and perhaps there is potential
> for
> WS-Policy to leverage the authentication context work. If and when
> WS-Policy is brought to an open standards organization, perhaps that
> forum
> would be appropriate for discussing such combinations.
>
> Do you agree?
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia Mobile Phones
>
>
>
>
>> -----Original Message-----
>> From: ext Anthony Nadalin [mailto:]
>> Sent: Wednesday, October 15, 2003 4:03 PM
>> To:
>> Subject: RE: [security-services] Groups - authentication-context.pdf
>> uploaded
>>
>>
>>
>>
>>
>>
>>
>>> This enables SP to make the right business decision and execute the
>> transaction properly.
>>
>> This is a prime example of policy (WS-Policy), not
>> authentication context
>> as it goes beyond authentication
>>
>> Anthony Nadalin
>>
>>
>>
>> To unsubscribe from this mailing list (and be removed from
>> the roster of the OASIS TC), go to
>> http://www.oasis-open.org/apps/org/workgroup/security-services
> /members/leave_workgroup.php.
>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/security-services/
> members/leave_workgroup.php
> .
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/security-services/
> members/leave_workgroup.php.
>
