# FlexCreds: evolution of compatible credentials

*Note: This work is very similar to something our team lead has done recently for Ceramic network, https://github.com/ceramicstudio/VerifiableCredentialDemo, where we provide a module to convert and add the signature line required.*

We are excited to work on this project with AnonCreds to create flexible credentials able to be used in the AnonCreds or Verifiable Credentials ecosystems, and to provide clean libraries and documentation that enable applications to easily add capabilities. Our vision is that because the high level primitives are nearly equivalent, this project could enable applications to provide credential capabilities and choose which of several underlying implementations to include, perhaps depending on privacy or compatibility requirements.

## Proposed Process

### Phase I: Community Discovery and Spec Modifications
Perform community consultation to evaluate the different approaches to modifying the Anoncred spec, in discussion with the BC team, and propose the changes to the spec in order to achieve the goals:

* Creation and inclusion of multiple signatures and types.
* enable requests for credentials and presentations to specify AnonCred or VC
* enable holder to add signatures to add capabilities to existing credential

Some decisions that may come up, pending our greater understanding of the ecosystem:

* Should we define schema elements that enable VC compatibility
OR
add an optional flag similar to support_revocation, like support_verifiable_credential
and add the additional fields in the credential definition

* Do we want to add additional methods likeVC credential request, VC presentation request, response, etc
OR
include a 'credential type' field on all requests and responses for "flexcreds"

* are we going to brand a new credential FlexCreds or how best to communicate these capabilities? Generally, what should be the interface and primitives exposed? Should we be making the type of credential surfaced or generally not apparent except as needed?

* the specific "Interesting Details" listed, ie issuance date, unlinkability/revocation, context to be included or not

This phase acts as a decision gate for the rest of the project. Assuming the decision is to continue:

### Phase II: Updating AnonCreds Rust Implementation:

From an initial review, we think using traits may be a good idea to keep the interface clean.

**Traits as the Backbone: Utilizing Rust's trait system to achieve flexibility and modularity:**

impl Credential for AnonCred {...}
impl Credential for VCCred {...}

This approach ensures we can extend our system without excessive overhead. Specialized methods will be introduced as necessary.

Revocation Aspect: We're considering a RevocableCredential trait. Given the dynamic nature of credentials and privacy implications, it makes sense to have credentials that can be revoked when needed.

Integration Details: Our focus will be on ensuring seamless transitions between AnonCred and VC requests, and allowing credential holders the capability to add signatures as enhancements.

Robust Testing: Implementing comprehensive unit and integration tests to affirm reliability.

### Phase III: Agent App Demonstration - "Aries FlexCred Agent":

**User Onboarding:**

Registration in the Aries mobile wallet, facilitating DID and private key setup.
Credential Management:

Users can request, receive, and categorize credentials; for example, placing transcripts under an "Education" category.
Secure communication and credential exchange is supported using CHAPI or DIDComm.

**Credential Presentation:**

Notifications alert users of incoming requests from verifiers, prompting them to choose appropriate credentials and decide on disclosed details. Leveraging the inherent privacy features of AnonCreds, users can selectively disclose information, ensuring minimal exposure of their personal data to verifiers.

**Behind-the-Scenes Mechanics:**

Highlight the agent app's utilization of the modified AnonCreds Rust implementation for generating and sending proofs.

**Verification Feedback:**

Post-verification, users receive feedback within the app about the verification status of their shared credentials.

### Summary
Due to the clear proof of concept application provided, this project should be fairly straightforward. The challenge we see is in modifying the specification and Rust implementation without adding unnecessary complexity, and in clearly communicating the new capabilities both to developers and end users. We anticipate tackling these challenges in partnership with the community in order to produce a genuinely useful result.

### Team highlights

Note that **Belsy Yuen** on our team implemented the revocation capabilities for AnonCreds.

Relevant team github repos & contributions:

https://github.com/hyperledger/anoncreds-rs/commits?author=whalelephant (AnonCreds)
https://github.com/whalelephant
https://github.com/avida-zone (alternative wallet similar to Aries)
https://github.com/Cooperation-org/LinkedClaims (Cooperation-org is owned by What's Cookin' Inc team)
https://github.com/ceramicstudio/VerifiableCredentialDemo
https://github.com/Cooperation-org/linked-trust-impact-eval
https://github.com/whitedragon001227/terra-marketplace-cw721-1155-.git
https://github.com/whitedragon001227/glow-contracts.git (Rust)
https://github.com/gvelez17/webglimpse (older Open Source project with 19 stars)