Hi Yinxing, (cc:ed to abfab list for discussion),
Some answers to your answers below, followed by some suggested rewording.
> For the text "but that's not the purpose of this document", the clarification
> is as follows:
> (1), Federated identity is in the scope of abfab wg,and the case also
> supports non-web application.
> (2), in the section 3. Context of Use Cases in this document
> (draft-ietf-usecases-01), it says:
> In the interest of promoting the development of technology of broad
> applicability, the present authors welcome use cases and requirements
> from other sectors and communities.
1 - Yes, federated identity is in the scope of the WG. But the purpose of the
working group is not to explain why federated identity in general is a good
thing.
2 - Absolutely, please don't misunderstand, I'm happy to accept all valid use
cases that people come up with...
> Yinxing#2>The point is that the mobile network infrastructure has already had
> security capabilities (e.g. authentication, integrity and confidentiality )
> which is mandatory for user equipment attacked to network.
> Application can make use of this capability without duplicating the similar
> task done in network layer. As to desktop or laptop, when they connect to the
> network, the authentication is performed in other way provided by network
> operators.
OK, yes, I see that in your particular use case the process would be slightly
different than in normal use cases, and so therefore might well be worthy of
including in the use case doc - if your separate I-D gains consensus.
If it is to go in the use case doc, however, the current text doesn't really
fit in the document as it stands (both in terms of style and content). It
really does say a lot of unnecessary things (e.g. federated access is good
because it means users don't have to remember multiple credentials) and things
that I'm sure people (including myself) would argue with (e.g. do all telecom
operators always provide trusted identity? I think not!).
So I've had a go at writing my own version of this use case trying to draw out
the main points that you're arguing for. Does this capture what is trying to be
said sufficiently well? (It still needs tidying up, but I'm just trying to get
the gist of your use case first).
=====
Accessing Applications from Devices on a Mobile Telecoms Infrastructure
Mobile telecom operators typically have the following properties:
* A large collection of registered users, many of whom may have identities
registered to a fairly high level of assurance (often for payment purposes).
However, not all users will have this property - for example, non-contract
customers in countries with low levels of identity registration requirements.
* An existing network infrastructure capable of authenticating a mobile
device, and by inference, its owner.
* A large collection of applications (both web-based and non web-based)
that its users wish to access using their mobile device. These applications
could be hosted by the mobile telecoms operator directly, or could be any
application or system on the internet - for example, network messaging
services, VoIP, email, etc.
At present, authentication to these applications will be typically configured
manually by the user on their mobile device but inputting their (usually
pre-provisioned out-of-band) credentials for that application - one per
application.
The use of ABFAB technologies in this case, via a mechanism dubbed "federated
cross-layer access" (see [ref]) would enhance the user experience of using
these applications on mobile devices greatly. Federated cross-layer access
would make use of the initial mutual authentication between device and network
to enable subsequent authentication and authorisation to happen in a seamless
manner for the user of that device authenticating to applications.
=====
Rhys.
--
Dr Rhys Smith: Identity, Access, and Middleware Specialist
Cardiff University & JANET(UK)
email: [email protected] / [email protected]
GPG: 0xDE2F024C
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
