Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validation of payload of TrustedIsssuerRecord #65

Closed
philpotisk opened this issue Nov 15, 2021 · 1 comment
Closed

Validation of payload of TrustedIsssuerRecord #65

philpotisk opened this issue Nov 15, 2021 · 1 comment
Labels

Comments

@philpotisk
Copy link
Contributor

Method validTrustedIssuerRecord

private fun validTrustedIssuerRecord(tirRecord: TrustedIssuer): Boolean {
should be extended to validate the JWT as well as the decoded payload of the token.

@victorholo
Copy link
Contributor

Hello,

We are part of EBSI4RO and have been working in understanding EBSI and Walt.id and also have been looking over the Policies. We have just been added in the trusted issuer registry and our attributes do not match with the ones tested against in the mentioned method validTrustedIssuerRecord.

Here is our issuer entry with it’s attribute https://api.preprod.ebsi.eu/trusted-issuers-registry/v2/issuers/did%3Aebsi%3AzfPHQeMuKeSE7Ff35BcH7xL
At this moment I couldn’t find a TIR entry with the strings which the code is testing against for comparison.

As seen here: https://ec.europa.eu/cefdigital/wiki/display/EBSIDOC/Trusted+Issuers+Registry+API#attribute+data+model the hash represents the keccak256 hash of the payload and the body is base64 encoded content.

I believe there isn’t any reason to validate the hash, considering it is being used as an identifier, but instead decode the base64 body which would result in something like:

{
   "@context":"https://ebsi.eu",
   "type":"attribute",
   "name":"issuer",
   "data":"5d50b3fa18dde32b384d8c6d096869de"
}

I haven’t been able to figure out what the data represents, but seems that the name and type field might be more appropriate to test against.

Also, is it safe to assume we will always have this entry at the first index of the attributes array?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants