- Notifications
You must be signed in to change notification settings - Fork1
mDL/mdoc, Cbor, COSE/JOSE Kotlin multiplatform monorepo
License
Sphereon-Opensource/mdoc-cbor-crypto-multiplatform
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Please be aware that this library still is in alpha state and far from complete. Major changes are likely to happen
This is a multi-platform mDL/mdoc and CBOR library. The goal is that this library can be used natively on Android, iOS,apple, linux, windows as well as in JVMs and Javascript/Typescript.
Certain functions are delegate to native platform functions and you will have to provide these yourself. We have donethis to not make to many assumptions on crypto libraries. The library does support generic Cose and Jose keys, but onlyfor transport, not for signing/verification. For these operation we delegate to a service you will need to provide.Having said that we provide some implementations you could register/use on your platform.
A multi-platform CBOR library. The goal is that this library is to be able to work with CBOR data. It can be used natively on Android, iOS,apple, linux, windows as well as in JVMs and Javascript/Typescript.
A multi-platform JOSE/COSE library. The goal is that this library is to be able to convert COSE/CBOR keys and JOSE JWKs and other primitives intoone-another. The library also has support for X.509 Certificate chain validations. It can be used natively on Android, iOS,apple, linux, windows as well as in JVMs and Javascript/Typescript. Seethecrypto README for more information.
You will notice that we have primitive CBOR objects likeCborString
,CborInt
, representing their programminglanguageprimitive object counterpartsString
,Int
etc. These are also handy outside of the MDL/Mdoc scope for general CBORprocessing. Then we also have more complex CBOR objects, like forinstanceDrivingPrivelegesCbor
, representing ISO/MDL Driving Privileges in CBOR format and usingCbor
primitiveobjects andCbor
complex objects internally, also sometimes using delegation structures to ease serialization. At the same time wealso haveaDrivingPrivilegesJson
object, which contains programming languageprimitives and other Json objects containing simple primitives/objects.
Most complex objects have these dual CBOR/JSON views. Strictly speaking we could have skipped thedualCbor
andJson
view approach as the serialization solution would be able to handle it. Introducing the CBORobjectshelps us ease the non-reflection based approach of this serialization solution.The current serialization solution has support for ourmain target platforms (Kotlin, JVM/Java, iOS, Android, Javascript/Typescript/React-Native )
However that is not main reason for the split. We wanted to:
- have separate CBOR and COSE cross platform support not tied to MDL/Mdocs in the future.
- be able for users to decide whether they want to do JSON serialization for instance when incorporating thislibrary in a JSON/REST based API. The Json counterparts are directly serializable to JSON. Obviously MDL/Mdocinteractions are done almost entirely in CBOR (some exceptions for server based retrieval/JSON)
- have strongly typed objects, including CBOR/CDDL information coming from CBOR interactions.
- have simple objects for developers to deal with
- ensure that JSON serialization and CBOR serialization cannot be in eachothers way.
Cbor
andJson
objects can be directly converted into their counterparts, by simply callingtoCbor()
andtoJson()
respectively. The complexCbor
objects also have builders, which can be instantiated usingCbor
primitivesandCbor
complex objects, but also by calling the builder methods that are more focused on simple programming languageprimitives andobjects. This allows developers to create CBOR objects easily and leaves them the choice to construct aJson
object and callingtoCbor()
on it or using the builder on theCbor
object.Construction of the Json objects should be straightforward especially with programming languages supporting namedparameters; Since we do not know whether all (future) targets will have this easy approach, and because builders arealso a popular way to construct objects, we decided to include builders for almost all CBOR complex objects.Most objects coming from a MDL/Mdoc interaction thus will be in the CBOR object format. Converting these simply meanscallingtoJson()
on them to make them easier for developers to deal with. So to conclude:
- Produced by MDL/Mdoc interactions:
<ObjectName>Cbor
Object -> calltoJson()
- to be consumed by MDL/Mdoc:
<ObjectName>Json
object -> CalltoCbor()
, or<ObjectName>Cbor
object -> Call the builder, usingJson
and primitive arguments orCbor
names parameters
There is one caveat for certain JSON properties. Whenever we use polymorphic values, there typically is a need toprovide the CDDL value as well. This has to do with the fact that we otherwise would lose information when going fromJSON to CBOR. For instance dates in CBOR can be expressed using strings and numbers. Then there are long and shortdates. So whenever we encounter a JSON number or string, we would not know how to map that to Cbor. Of course this isonlyapplicable to where polymorphism is possible for a property. In these cases the CDDL value is made mandatory. These arethe only places where the CBOR types seep into the JSON types.
About
mDL/mdoc, Cbor, COSE/JOSE Kotlin multiplatform monorepo
Resources
License
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Releases
Packages0
Contributors4
Uh oh!
There was an error while loading.Please reload this page.