Shared Credentials

Axel likes the idea of using network authentication as a second factor.

So if you are using your home DSL connection then this access is used as a second factor for your T-Home account. And If you have a T-Mobile internet connection using your mobile phone then that access is used as a second factor for your T-Home authentication. I like that.

Of course, network authentication isn't only relevant as providing support for some other primary credential - in some cases it can provide sufficient assurance in its own right.

For example, in Axel's DSL scenario above, the network authentication itself could enable access to some class of resources without requiring an additional password or other factor.

Here is the rub though. If mere access to the DSL line is going to be considered as providing sufficient assurance for access to some set of resources - then those resources have to be appropriate for all users that can access the DSL line.

A shared credential implies shared resources.

For instance, the 'DSL Access Authentication (by its very nature shared amongst the members of the household) could enable access to a shared family calendar and a family photo album. Access to a non-shared resource (e.g. daughter's Inbox) would require presentation of a non-shared credential.

In a federated scenario (ie. the entity to which the shared credential was presented asserts to that fact to an RP), the last implies the need for an RP to be able to phrase the request

'I know that you've previously asserted to me that the user was authenticated, but at the time you only told me he/she was a member of the group that had access to some shared credential. Now I need you to actually tell me which member of that group he/she is.'

The sequence might be

1) User presents shared credential (i.e. network authentication) to IDP
2) IDP asserts shared identity to RP
3) User given access to shared resource
4) User attempts to access non-shared resource
5) RP indicates it needs non-shared authentication
6) IDP authenticates user as individual (password etc)
7) IDP asserts individual identity to RP
8) User given access to individual resource

NTT & France Telecom (interested as we are in leveraging the value of network authentication) have proposed an extension to SAML 2.0's Authentication Request to support this distinction.

A mobile phone network authentication, as the phone is not typically shared amongst a set of users, doesn't present the same twist.