This is a call for feedback on the topic of bringing interoperability and composability together with the privacy-friendly design of Internet Identity and other identity providers. This is an initiative of the Identity and Authentication Working Group. Community members are encouraged to actively participate and take part in the monthly working group sessions.
This is a live document and will be expanded continuously as we go along the process outlined below.
The goal is to derive the requirements, a solution design and ultimately an MVP implementation to address the most pressing needs of the community regarding interoperability & composability with respect to identity on the IC.
This feature will go through the following process:
- Validate the problem statement (current step)
- Gather requirements from the community
- Form consent in the Identity and Authentication Working Group on a consolidated set of MVP requirements.
- Start process to find possible solutions to address the MVP requirements.
- Form consent in the Identity and Authentication Working Group on an implementation ready MVP specification.
- Create an NNS proposal to vote on whether the MVP spec should be accepted as a standard.
- If the NNS proposal is accepted: implement the specification in the IC (as required to unblock identity providers).
We use GitHub to organize our collaboration but also want to keep the process lightweight and easy to participate in. As such we can use issues to track and discuss concerns community members might have. The goal should be to reach consent by dealing with all issues raised in a manner acceptable to all participants.
If this is not possible in a reasonably efficient way the working group may need to revise this process.
The problem can be phrased slightly differently depending on the type of identity provider issuing the delegations:
- if application specific principals are used (and not using the delegation target): The goal of this project is to provide means for users to allow services limited access to other services using their application specific principal.
- if global principals are used (in conjunction with delegation targets): The goal of this project is to provide means for users to allow additional delegation targets with limited permissions.
The following is a flow loosely based on the OAuth 2.0 / OpenID Connect flows that are generally used by Web 2.0 applications. A flow like this will be familiar to most users. Nonetheless, it should only be used as a starting point and can be shaped to the needs of the community.
This is a mock-up of what a consent-screen could look like. The goal should be to clearly communicate to the users what the implications of consenting to permission delegation are.
Identity providers are free to implement this screen as they wish. It is included here as a starting point for the discussion regarding user interaction.
In order to solve this problem, there are a few parameters that need to be specified in the architecture:
- How to specify permissions
- Format
- Semantics
- Human readable descriptions
- How to deal with internationalization
- How to issue credentials
- Credential validity durations
- For a single session
- For a longer time period
- How to revoke permission delegations / credentials
- Which component verifies the credential matches the permission given on a specific canister call
- The service provider dapp
- The replica
- How to collect consent from the user
- How to handle revocation of credentials
- How to handle unlinkability between principals
- It is likely that unlikability cannot be maintained in the general case: Consider a service provider that allows delegation of a permission that gives consumer access to a function that reveals the caller principal. However there might be a means to mitigate this issue.
- Retain extensibility of the protocol for further development
- E.g. allow delegation of capabilities between canisters
- What if the canister call (consumer → service provider) requires payment?
- Out of scope, needs to be handled by the consumer
- Provide means to allow users to pay for the access
- Do we need to maintain compatibility with Web 2.0 services
- for consumers
- for service providers
- Given an existing infrastructure dapp such as Internet Identity or the NNS dapp:
- expected set of permissions
List of requirements gathered so far:
| # | Requirement | Description | Source |
|---|---|---|---|
| R1 | Dapps can specify permission sets that can be requested by other (third party) services. | The permission sets should consist of the following information:
|
|
| R2 | Permissioned delegations allow a service to access another using the application-specific principal of the other service. | Given a user that has delegated some permissions from service B to service A. Service A will be able to:
|
|
| R3 | Permissioned delegations should reveal as little information as possible about the attributes of the user. | A service should learn as little information as possible from the permissioned delegation about the user whose permission it received. (However, this does not prevent services from revealing the user principals themselves.) |
|
| R4 | Once granted, a dapp should not have to request the same permissions again within the validity period of the issued credential. | Example:
|
|
| R5 | Developers should have the ability to offer users the functionality to list and revoke granted permissions. | The platform should allow developer to build infrastructure for users which allows them to:
|
|
| R6 | The replica must enforce the restrictions associated with the granted permissions. | Similar to the existing delegations, the replica should validate and check that the current call is allowed given the permissions granted. | |
| R7 | The user consent-flow must be feasible for all combinations of supported platforms. | The flow is feasible for the following participants:
|
|
| R8 | Permissioned delegations must be robust against changes. | If a developer makes changes to a permission set, previously issued consents must become invalid. This is because users and developers have a different notion which changes to permissions are compatible:
|
|
| R9 | Permissioned delegations must be usable by application front-ends as well as canisters. | The permissioned delegations should be able to be used for front-end canister calls and inter-canister calls. | Björn Tackmann |
| R10 | Cross-chain interoperability | The solution should look to be compatible to standards that allow cross-chain interactions, such as:
|
https://github.com/MioQuispe |