search

openwallet-foundation-labs / identity-credential

Apache License 2.0
163 stars 83 forks source link

Provisioning specification #103

Open ceuser1 opened 2 years ago

ceuser1 commented 2 years ago

Are there any public specification regarding the provisioning? I don't think ISO 18013 talks about provisioning, and the ISO/IEC 23220 isn't available to public yet.

I am looking mainly at the ProvisioningSession and CertifyAuthKeysSession. For example

The only 'specification' I found is in the mdl-ref-server/README.md file. Where can I find more info about it?

davidz25 commented 2 years ago

The code in the repo is indeed based on a draft of 23220-3 from last year and these are only available to members of ISO SC17 WG4 as far as I know. You can get access by joining your national standards body associated with ISO (in the US it's INCITS, in the Netherlands it's NEN, in Germany it's DIN, and so on).

As to your questions

why first provisioning and then certify auth keys?

Because that's how the Identity Credential API works.

why two separate steps ('StartProvisioning' and 'com.android.identity_credential.StartProvisioning')? Looks like it could be done in one request.

Because you want to periodically refresh MSOs.

should the challenge really be fixed (FixedChallenge)?

Nope, both the server and client side bits of this is rough work-in-progress.

ceuser1 commented 1 year ago

One question while we are waiting for the 23220-3 to become public... is there an option to integrate the identification procedure to the provisioning protocol?

With identification I mean taking a selfie and photos of existing physical documents with your phone and send them to the backend. Backend would perform face matching of selfie and photo from the document, OCR of the document, validation etc... Only after the identification is successfull, the person can request the actual document from the backend.

In this scenario the first message wouldnt' contain the provisioningCode, but photos (selfie, front and back photos of the physical document, etc..), and the workflow would be a bit different. I'm not sure how flexible the 23220-3 standard is regarding those challenges.