You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Requested feature
Add OAUTH as an additional client authentication method specified in the policy files
Motivation
Currently, all of the participants in the Veracruz computation are authenticated via self-signed client certificates that are specified in the policy file.
This makes the policy file difficult for humans to parse and comprehend. Additionally, not all users find client certificates intuitive to create or to use.
If we could add OAUTH as an additional participant authentication technique, it might (this bears investigation) make the policy file more human-readable. Also, using login information is much more intuitive for most users as opposed to certificates.
It is my understanding that most of the world works with OAUTH2.
Additional context
It is also my understanding that OAUTH2 is not as prescriptive as OAUTH version 1, and that this results in different code being needed for each OAUTH2 service that you use. Thus, adding OAUTH2 support might require that we write for specific OAUTH2 providers (such as google, microsoft, amazon, etc.) instead of having a general solution that works for all of them.
It is also important to note that by including OATH identities in a policy file, the providers of those identities effectively become part of the root of trust of that computation.
The text was updated successfully, but these errors were encountered:
Requested feature
Add OAUTH as an additional client authentication method specified in the policy files
Motivation
Currently, all of the participants in the Veracruz computation are authenticated via self-signed client certificates that are specified in the policy file.
This makes the policy file difficult for humans to parse and comprehend. Additionally, not all users find client certificates intuitive to create or to use.
If we could add OAUTH as an additional participant authentication technique, it might (this bears investigation) make the policy file more human-readable. Also, using login information is much more intuitive for most users as opposed to certificates.
It is my understanding that most of the world works with OAUTH2.
Additional context
It is also my understanding that OAUTH2 is not as prescriptive as OAUTH version 1, and that this results in different code being needed for each OAUTH2 service that you use. Thus, adding OAUTH2 support might require that we write for specific OAUTH2 providers (such as google, microsoft, amazon, etc.) instead of having a general solution that works for all of them.
It is also important to note that by including OATH identities in a policy file, the providers of those identities effectively become part of the root of trust of that computation.
The text was updated successfully, but these errors were encountered: