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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] Groups - authentication-context.pdf uploaded


Anthony,

I can only speak on behalf of the mobile folks, but find below a
simple use case example for Authentication Context.

>
>Frederick,
>
>Some questions:
>
>(1) What is the requirement driving the Authentication Context 

There are a number of business use cases that drove the development
of this specification, most of those use cases came from the companies
that are users of a solution, not from product vendors. For mobile space,
the three mobile profiles (Contract, DigitalID and Unregistered) were authored
and contributed by the three mobile operators who are members in Liberty.

A simple use case could be:

A Service Provider having a business relationship with Mobile Operator A, 
has an end user accessing their service which requires both authentication
and a low value payment (let's say < 5 USD, for a Java Game). The SP has
a business agreement with Operator A which states that for any customer
of Operator A which is postpaid, Operator will guarantee the transaction up to
5 USD, for any customer of Operator A which is prepaid (unknown to operator A),
SP has to do an online payment transaction before delivering the service, since
operator A doesn't "guarantee" the payment, i.e. there needs to be money on the
prepaid account for the transaction to complete. In this scenario, it is essential
for the SP to know if the end user and customer of Operator A is either
Mobile Contract = postpaid  = payment "guaranteed" by operator A
Mobile Unregistered = prepaid, no "guarantee" by operator A

This enables SP to make the right business decision and execute the transaction
properly.

>? Is it just tightly wrapped with the Liberty work that it can't be separated ?

No it's not, it has been explicitly designed so that it can be separated.... 

It's addressing real business needs of a number of customers.
The example above is just on of the many business use cases related
to authentication context.

>(2) What is the value of the Authentication Context, seems 
>like its just metadata that has no validity ?  Seems like its being used to 
>attest to the strength of the assertion somehow ?

Strength of an assertion is subjective and a business decision, authentication
context simply allows one to request a certain authentication mechanism and
then to be informed what mechanism was actually used. Any other semantics
are related to the business model used within a specific transaction.

-Timo


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