Open OR13 opened 1 year ago
anderseknert
commented
1 year ago Hi @OR13 👋 Are there any specs on this yet that are not in draft status? It'd be good to know that whatever integrations are added don't depend on specifications that are WIP. Other than that I think verifiable credentials in particular is an interesting prospect for OPA.
Any Go libraries you'd recommend for CBOR / COSE integration?
OR13
commented
1 year ago WebAuthN which is also used with passkeys, uses CBOR:
Apple uses CBOR in their digital wallet api:
Several FIDO alliance specifications use CBOR & COSE
CBOR / COSE RFCs:
The related IANA Registries:
https://github.com/veraison/go-cose has minimal dependencies, and one of them would be needed for marshal / unmarshal of cbor.
anderseknert
commented
1 year ago That's very useful! Thanks @OR13 👍
thomas-fossati
commented
1 year ago https://github.com/veraison/go-cose has minimal dependencies, and one of them would be needed for marshal / unmarshal of cbor.
adding 1 bit to Orie comprehensive refs: the CBOR package go-cose depends on is github.com/fxamacker/cbor/v2.
henkbirkholz
commented
1 year ago To me it seems that everyone at some point arrives at the "policy language" decision point. OPA/rego support for CBOR seems to be one of the options that virtually everybody can agree on. Speaking for myself, I am in full support.
thomas-fossati
commented
1 year ago There are many use cases where CBOR / COSE is starting to gain adoption side by side existing JSON / JOSE infrastructure, one example can be found here:
In such cases, it can be advantageous to be able to write policies that apply to both CBOR and JSON in the same policy language.
Big 👍
Allowing relying parties involved in CBOR exchanges to be coded as simply as https://play.openpolicyagent.org/p/fBydqNm0G0 would be awesome.
stale[bot]
commented
1 year ago This issue has been automatically marked as inactive because it has not had any activity in the last 30 days. Although currently inactive, the issue could still be considered and actively worked on in the future. More details about the use-case this issue attempts to address, the value provided by completing it or possible solutions to resolve it would help to prioritize the issue.
ivarprudnikov
commented
1 year ago I believe the only viable alternative at the moment is to convert cbor to json before passing to the policy agent (rego). This will lose the ability to verify the signatures though.
BTW not entirely sure how any such extensions (if implemented) will have the impact on the alternative implementations for other languages like https://github.com/microsoft/rego-cpp/
What is the underlying problem you're trying to solve?
We want to process CWT and COSE Sign 1 with policies similar to the ones we use for JWT / JWS.
Describe the ideal solution
Built in support for CBOR encode / decode, COSE sign and verify.
Similar to the existing support documented here:
Describe a "Good Enough" solution
I suppose being able to marshal / unmarshal might be a starting point.
Additional Context
There are many use cases where CBOR / COSE is starting to gain adoption side by side existing JSON / JOSE infrastructure, one example can be found here:
In such cases, it can be advantageous to be able to write policies that apply to both CBOR and JSON in the same policy language.
There are also cases where COSE might secure JSON or JOSE might secure CBOR, and being able to write policies to handle these cases would help ensure producer and consumer interoperability.
W3C Verifiable Credentials is one such use case.
IETF SCITT is another such use case.