Hi Jon,
Thanks for your comments.
On Thu, 01 Oct 2020 01:14:22 +0200,
Jon Callas wrote:
I can think of another utterly different syntax, though, that would
be similar to what Vinnie Moscaritolo and Tony Mione did in "PGP
Tickets" which you can find as an I-D at
<https://tools.ietf.org/html/draft-moscaritolo-mione-pgpticket-03>.
The idea here would be that it would be like an Attribute
Certificate, or a capability. It would permit (e.g.) a sysadmin to
be able to say that the holder of a key is the owner of a file path
on a server. (Vinnie wrote software for this exact case. You could
sign in to a file server with an OpenPGP key and the ticket could
describe what authorizations you had.)
I don't think this is exactly what you want, but it's close. An
advantage of the ticket approach is that you don't need anyone's
permission to do it. It could literally be a bit of defined YAML or
JSON that you clear-sign as text, and then poof, you're done. You
don't have to listen to any of us give helpful comments about what
you want to do, you just do it.
Thanks for pointing this out, I was not aware of this work. I have a
special place in my heart for object capability systems, so I was
happy to learn that some work has already been done on that in the
OpenPGP ecosystem.
I'm a bit confused, however, how PGPtickets are analogous to social
proofs. A social proof is an identity ("my handle on this service is
X"). PGPtickets are authorizations. When I create a social proof,
I'm not normally delegating any authority; I'm advertising an
identity. And, an authorization in the o-cap world is normally free
of identity information (authorization-based, not identity-based,
access control is the mantra).
Thanks for any feedback.
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp