r_parse_message_3: Tolerate unparsable credential-by-value#271
r_parse_message_3: Tolerate unparsable credential-by-value#271geonnave merged 5 commits intolake-rs:mainfrom
Conversation
Users must already be aware that what is returned could be incomplete (i.e. have no key) because it could be a credential by key ID; now it could also be a credential-by-value that is not in a format that the limited Lakers credentials parser recognizes.
|
But what if the credential is indeed invalid? I think this changes the semantics of the API, as now the application cannot know if the credential was parsed or not. One hacky way would be to add a Right now I can't think of a better solution without an API re-design. |
|
I don't think that Lakers can be expected to differentiate an invalid credential from one that it just does not understand. The way it currently exposes properties rather than accessors makes the differentiation between "has no key" and "the key is empty" hard, and improving that may be API change -- we can make the properties private, maybe turn some of them into an Option, and do all kinds of enhancements. To enhance this change in isolation, we could add an |
|
Ok. The spec indeed says in Section 5.3.3: Since it is not obvious why we are ignoring the error in the proposed change, there could be a comment in the else clause about leaving the credential processing to the application. |
|
Good point, comment was added. |
This enables using CWTs as values, provided that in the same step as where the user expands a credential-by-kid into a full credential, they also parse any non-CCS (or differently shaped CCS) values such as a CWT into the credential (left as it is), the key and the key ID.
This builds on #270 and addresses its usability caveat described in #269 (comment)
I still think we may want to elaborate the CredentialRpk type into differentiating at the type level whether it is valid (has KID, key and credential) or just partial (in the shapes "we parsed it already, it is valid", "we only have the KID" and "we only have the credential value but no keys", possibly others in the future), but that's API rework, and this enables things with the API as we have it.