Misunderstanding of what AuthorizedNamespaces is

[davidz25]

Section A.2.4. Credential Response says the following

The value of the credential claim in the Credential Response MUST be a string
that is the base64url-encoded representation of the CBOR-encoded IssuerSigned
structure, as defined in [ISO.18013-5]. This structure SHOULD contain all
Namespaces and IssuerSignedItems that are included in the AuthorizedNamespaces
of the MobileSecurityObject.

According to 18013-5 AuthorizedNamespaces is a mechanism for the issuer to convey that DeviceKey is authorized to sign data elements in that name space and to be returned in DeviceSigned. So it doesn't make any sense to say "This structure SHOULD contain all Namespaces and IssuerSignedItems that are included in the AuthorizedNamespaces of the MobileSecurityObject.". (Also, if you look at MSOs being minted today across e.g. US mDL issuers, no-one is actually using DeviceSigned at all to return data elements, as far as I know.)

I also don't think it make sense to specify what the structure SHOULD contain, I mean, it's already completely specified by 18013-5 what it contains. I would just strike the entire last sentence in the quoted paragraph.

[andprian]

I agree the paragraph needs correcting. However we should not restrict the response to IssuerSigned. DeviceSigned should be allowed as well.
As for the content of the structures, I agree we do not need to specify again their contents, just refer to 18013-5 if this spec introduces no modification.

[davidz25]

DeviceSigned should be allowed as well.

So, yeah, I mean, I don't disagree. But I don't think we can say anything about the encoding of the data... because the whole point of DeviceSigned data elements is that the device comes up with them using multiple signals, not just what the issuer tells them, if anything.

Here are three examples:

• age_over_18 could be a device-signed data element and in this case there are two signals, namely birth_date and also what the device believes to be the current time.
• device_matched_authorized_holder could be a device signed boolean calculated by using sensors on the device and comparing against issuer-provided biometrics provided out-of-band, set to true only if there's a match.
• holder_verified_email_address device signed tstr which is the email address obtained from e.g. asking the user and verifying it out-of-band.

At least this is the spirit of device-signed and examples often used in ISO.

So IOW, it's hard to specify what format the data used - if any - should be transmitted by the issuer. There's just nothing we can say about it. I do think we should allow implementations to put other things in IssuerSigned map but I don't think it needs to be standardized.

[Sakurann]

@davidz25 could you please do a small quick PR removing This structure SHOULD contain all Namespaces and IssuerSignedItems that are included in the AuthorizedNamespaces of the MobileSecurityObject.. ?