Actually, this makes a lot of sense. I believe that such URLs can be
made sufficiently secure by signing with a key bootstrapped from the
password (something like PAK or EKE). But they ought to remain secret,
which is pretty impossible to ensure, or they must be made unreusable
by anyone except the intended party. I guess one way is to build the
delegation into the URL by providing the recognizable identity string
(like OpenId) on which the recipient will need to authenticate.
One question: how would that fit into the present OAuth plan? Could we
standardize the delegation URL?
Igor
P.S.: I just wanted to clarify that I see the promise in OAuth to be
used in far more sensitive settings. For instance, I would consider
delegation (to an insurance agent) to access medical data or another
private record. There is also an interesting proposal from Deutche
Telecom, related to SIP, already on the table.
This is why I am a proponent of a general secure solution as a default.
Eve Maler wrote:
What's generally done today (think Google Calendar, Flickr, etc.) is use
"private" URLs and mail them around. It doesn't really meet anyone's standards
for controlling access to anything valuable -- but it sure is convenient. :-)
Eve
On 14 Jan 2010, at 11:53 AM, Igor Faynberg wrote:
John Kemp wrote:
...
What delegated authorization protocol should be used to deal with those "not so
serious" use-cases then, if OAuth makes them too expensive?
I expected this question and dreaded it. I don't have a good answer, and I don't think
there is one. (In my defense, the airport security cannot find the way around the
wait-wait-wait/shoes-off/belts-off/watches-off routine for "good" people--who
are actually the majority.)
One not-so-good answer, but--I think--a workable one is to consider an
(enumerated type) parameter carrying a required security value, something that
would have to come from the user initially, and then specify TLS or any other
cryptographic delicacy based on such value. The only problem is that end users
might happily settle for the highest security, anyway (unless they have to pay
for it).
Igor
Eve Maler
[email protected]
http://www.xmlgrrl.com/blog
Eve Maler wrote:
What's generally done today (think Google Calendar, Flickr, etc.) is use
"private" URLs and mail them around. It doesn't really meet anyone's standards
for controlling access to anything valuable -- but it sure is convenient. :-)
Eve
On 14 Jan 2010, at 11:53 AM, Igor Faynberg wrote:
John Kemp wrote:
...
What delegated authorization protocol should be used to deal with those "not so
serious" use-cases then, if OAuth makes them too expensive?
I expected this question and dreaded it. I don't have a good answer, and I don't think
there is one. (In my defense, the airport security cannot find the way around the
wait-wait-wait/shoes-off/belts-off/watches-off routine for "good" people--who
are actually the majority.)
One not-so-good answer, but--I think--a workable one is to consider an
(enumerated type) parameter carrying a required security value, something that
would have to come from the user initially, and then specify TLS or any other
cryptographic delicacy based on such value. The only problem is that end users
might happily settle for the highest security, anyway (unless they have to pay
for it).
Igor
Eve Maler
[email protected]
http://www.xmlgrrl.com/blog
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
