Re: Fwd: Re: [Cryptography] Encryption opinion
"Karp, Alan H" <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <8AD823089998C849A832D86972E69CD5419115D0@G4W3222.americas.hpqcorp.net> |
Ihab wrote: That point is actually tangentially supported by an anecdote about OAuth. As specified, the latter is arguably an ocap protocol. However, when last I checked, a few years ago, all the client libraries available were limited to a fixed enumeration of "scopes" (think: MAIL, DOCS, ...) and had no support for the (I guess preposterous) notion that one would want to mint a new "scope" for each resource (= object). So it's like, even when the basic tech is there, folks don't think to use it in an ocap manner. There’s been plenty of progress in the past few years, mostly due to the OAuth Bearer Token spec. People typically now talk about delegating tokens of reduced scope for individual resources, e.g, read permission on a file. They are still plenty of people doing it wrong, but we’re making progress. ________________________ Alan Karp Principal Scientist Enterprise Services, Office of the CTO Hewlett-Packard Company 1501 Page Mill Road Palo Alto, CA 94304 (650) 857-3967, fax (650) 857-7029 http://www.hpl.hp.com/personal/Alan_Karp From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, September 01, 2014 2:43 PM To: General discussions concerning capability systems. Subject: Re: [cap-talk] Fwd: Re: [Cryptography] Encryption opinion On Sep 1, 2014 2:35 PM, "Terry Hayes" <[email protected]<mailto:[email protected]>> wrote: > In other words, we know how to implement these patterns, but (unfortunately) nobody does it. I guess. Fwiw, if so, we should make these ideas more public though. Because -- > Instead, current implementations focus too much on who somebody is, rather than whether they should be able to do what is requested. That point is actually tangentially supported by an anecdote about OAuth. As specified, the latter is arguably an ocap protocol. However, when last I checked, a few years ago, all the client libraries available were limited to a fixed enumeration of "scopes" (think: MAIL, DOCS, ...) and had no support for the (I guess preposterous) notion that one would want to mint a new "scope" for each resource (= object). So it's like, even when the basic tech is there, folks don't think to use it in an ocap manner. Ihab _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk