Absolutely! In fact, client_id, should be presumed to be TOTALLY
different from the USIM (or ISIM) ID. The correlation of IDs is the
network's job. (Hui-Lan and I, along with two other researchers,
described how this can be done in a Bell Labs Technical Journal paper:
http://onlinelibrary.wiley.com/doi/10.1002/bltj.20426/pdf.)
Igor
Phillip Hunt wrote:
The notion of client instance ids (eg as suggested) by USIMs suggested may be a slightly different identify then envisioned by client_id.
I have mentioned the same issue before of identifying software separately from deployment instances which such a strong credential would map to.
They likely has to be addressed post 2.0.
Phil
On 2011-06-02, at 13:13, Thomas Hardjono <hardj...@mit.edu> wrote:
Thanks Igor,
If you bring smartcards into the picture, then it's a different
ballgame :)
If mobile phones are assumed to have smartcards (which is increasingly
true today via USIMs), then OAUTH can assume that native apps (running
on the phones) may have access to crypto-store. In this case the text
in Section 9 of draft-16 would needs changes/clarifications.
/thomas/
__________
-----Original Message-----
From: Igor Faynberg [mailto:igor.faynb...@alcatel-lucent.com]
Sent: Thursday, June 02, 2011 3:31 PM
To: Thomas Hardjono
Cc: Torsten Lodderstedt; OAuth WG
Subject: Re: [OAUTH-WG] review of draft-ietf-oauth-v2-16
Actually, for the devices that use smart cards (mobile devices, in
particular), this assumption is quite appropriate.
Igor
Thomas Hardjono wrote:
....
...
However, there is indeed the assumption in Kerberos/RFC4120 (and
in
the original Needham-Schroeder protocol) that the "client" can keep
secrets.
/thomas/
_______________________________________________
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
