Skip to content

Conversation

@FabioPinheiro
Copy link
Contributor

This is still a draft

Scecrtiong missing :

  • integration with this generic VDR interface
  • integration with the DID Service (propose a new DID service type)

Signed-off-by: FabioPinheiro <fabiomgpinheiro@gmail.com>
The DID Docuemtn is a simplacy version of the lasters status of the SSI.
That does not contains the `MASTER_KEY`; `ISSUING_KEY`; `VDR_KEY`.

Note: There are usa case where the SSI entry is not used as a DID. For example if you cares about managing Storage Entry.
Copy link

@mineme0110 mineme0110 May 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is confusing sentence for me , apart from the spelling mistakes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need review

Comment on lines +129 to +133
The data type for a Storage Entry is defined by the create event/operation. Depending on the filter used in the data, the following types of information/data may be stored:
- `E-7-3` - **bytes**: Represents a raw array of bytes.
- `E-7-4` - **Token Status List**: Represents a status list, as defined by https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/10/
- `E-7-5` - **bitstring_status_list**: ????
- `E-7-?` - **CID (content identifier)**: A reference to an IPFS document.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about storing just raw bytes and use media type to express how to handle the data? Application will interpret the data and protocol don't need to care what is being stored.

For example

  • text/plain; charset=utf-8
  • application/statuslist+jwt
  • one of options in bit string statuslist
  • other possible media types in SSI ecosystem

- The Indexer MUST be deterministic.
- The Indexer MUST be able to rever all steps to a previous `Cardano Block`.
Ideally, we recommend that the index is able to backtrack all the steps and unapply.
- It's not responsibility of the Indexer to validate the signature of the PRISM Operation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting take. Why isn't this similar to the resolver? Behind the VDR interface, client wouldn't have the ability to replay all the events? Maybe in this document Indexer != VDR driver?

@sonarqubecloud
Copy link

sonarqubecloud bot commented Dec 9, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants