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

Clarification of computation of rid #219

Open
pvillela opened this issue Dec 14, 2021 · 3 comments
Open

Clarification of computation of rid #219

pvillela opened this issue Dec 14, 2021 · 3 comments

Comments

@pvillela
Copy link
Contributor

The recommendation on how to compute the rid (revocation ID) in the revocation spec is a bit unclear:

It is RECOMMENDED to use the base64url encoding of the first 64 bits of the output of HMAC-SHA-256 (as specified in RFC 4868) on the user identifier using a 256-bit random secret key concatenated with the <<kid>>; i.e., `rid = base64url(hmac-sha-256(secret_key || <>, user_id)[1..64]).

What is meant by "user identifier" or user_id? What about the option of using the HMAC of the FHIR bundle? What about the option of using the HMAC of the patient resource?

There is also a formatting problem with the above quoted text, probably a missing backtick.

@christianpaquin
Copy link
Contributor

What is meant by "user identifier" or user_id?

The spec says: "Issuers MAY use application-specific user identifiers for this purpose"; it could be an internal database identifier for the user account, a health insurance number, etc.

What about the option of using the HMAC of the FHIR bundle? What about the option of using the HMAC of the patient resource?

If you can pick a rid at issuance, then I wouldn't recommend these methods. Picking and remembering a random value for the user would be better. The FHIR-derived values are necessary to identify the SHC which do not contain an explicit rid.

There is also a formatting problem with the above quoted text, probably a missing backtick.

Yes, the markdown to html rendering had some quirk. I think I fixed these in PR #218.

@christianpaquin
Copy link
Contributor

Latest changes in PR #230 (was PR #218) provide some clarifications. Can we close this, @pvillela?

@pvillela-del
Copy link

I'm good with it, thanks.

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

No branches or pull requests

3 participants