Inline credential offer lacks required metadata

[TimoGlastra]

When using inline credential offers (so using an object directly in the credentials array in an offer), the only required general property is the format. All other fields are declared by the format.

The credentials_supported from the issuer metadata however has a lot more properties that are supported by default. Most notably: cryptographic_binding_methods_supported, cryptographic_suites_supported and display.

I think this makes it very hard to use inline credential offers, as you have to guess which binding methods and cryptosuites the issuer supports.

How I'd first understood the different between referenced offers (with id) and inline is that inline offers may be used for one-off credentials, or credentials you don't want displayed in the public issuer metadata.

But there's a certain limitation to using the inline format, which I don't necessarily understand.

So my questions are:

• Is there a specific reason why the format of the credentials_supported and the inline credential offer format aren't aligned? Also for the formats the credentials_supported has more metadata (such as credentialSubject, order etc.. This seems to be useful to have with inline offers as well
• Would there be any objection to aligning the properties between credentials_supported and inline offers more? Without at least the cryptographic_binding_methods_supported and cryptographic_suites_supported properties, the inline offers seem hard to use to me. But even the display property would be nice to have in an inline offer. I can understand the display is a bit more risky, as someone could change the display properties somehow, while if you fetch it from a domain you're sure the properties are endorsed by the issuer. But if using a credential_offer_uri this is also migitated.

[nklomp]

What you see is that in a lot of cases the credential offer types and format are mapped onto the supported metadata (and the examples also imply that). We also do that, but IMO it should indeed be the one or the other. Or you provide an id and map that onto credentials supported (scopes in latest dev draft version), or you provide inline objects, but then allow for everything in there. The problem with current approach is you cannot map for instance two OpenBadge Credentials with the same format. Let's say I want to offer a slightly different version of a credential, but with the same type and format. Obviously I can have multiple definitions in the metadata and assign IDs/scopes to them. That also works with using ID/scopes in the offer. It would fail with the examples and how both we and Mattr have implemented it, as the types and format will never definitively identify which credential we would be talking about.

IMO scopes should just be made mandatory in the definition. Use scope strings in the offer, or have an inline credential definition, but then allow for everything in there (which means you will have to resort to a URI because of the size)

[TimoGlastra]

IMO scopes should just be made mandatory in the definition. Use scope strings in the offer, or have an inline credential definition, but then allow for everything in there (which means you will have to resort to a URI because of the size)

Yes, 100% agreed with this. I think you put it more clearly than me 😄

[TimoGlastra]

What you see is that in a lot of cases the credential offer types and format are mapped onto the supported metadata (and the examples also imply that)

I wasn't aware of this, and find that quite strange. This is exactly what the purpose of the id mapping is right?

[nklomp]

Yes and no. The id value and its mapping is gone in the latest dev spec. It has been replaced by scopes. But scopes can also span multiple definitions. Which then means you could not identify a single definition anymore. I do see the value of using scopes for multiple credentials, but at the same time I want full flexibility. Similar credential types/formats handled differently by the issuer, should be uniquely identifiable in metadata and thus also in the credential offer. Mapping types/formats from the offer onto the metadata is just prone to errors. Especially if a VC has multiple contexts for instance

[paulbastian]

I was about to open an issue on the same/similar topic, but I'm not quite sure I follow your point.
Wouldn't it be easier to just refer to the id value from the metadata in the credential offer credentials? That makes it very easy...
This would also be unified solution for all credential types, if I'm not mistaken

[TimoGlastra]

Wouldn't it be easier to just refer to the id value from the metadata in the credential offer credentials?

I think @nklomp is on the same side here. As I understand it he's also arguing to either refer using the id, or use an inline offer that supports all metadata properties as supported by the issuer metadata credentials supported:

Mapping types/formats from the offer onto the metadata is just prone to errors

I think we're all on the same page here! :)

[nklomp]

Yes, I am on the same page. I was merely trying to say that in the latest development version, there is no notion of an id anymore. It is replaced by scopes. A single scope can also be assigned to multiple credential types and format. So it is similar in a sense but also different. Since the scope is defined in metadata, how would I have a single credential type and format that can be part of a dedicated scope for this credential, but also part of a scope together with other credentials? Right now, that is not possible AFAIK as the scope is a singular string in credentials supported in the metadata.

So you could have individually identified credential types, combined credential formats and/or types, but not both at the same time. Let's say I have 2 credential types in 2 formats. Sometimes, I want to issue them together and let the user determine whether they want jwt or jsonld, then I could model that in the server metadata and use the appropriate scope parameter in the offer. However I am not able to create an offer for one of these credentials for instance, only for a jwt format.

[Sakurann]

would it be better to revert to a previous option where a string passed in the credential offer's credentials object is identifier, instead of scopes?

[TimoGlastra]

Maybe, but that's another topic I think. I opened this issue specifically targeted at inline credential offers, not the reference to the issuer metadata. It feels a bit weird that you can't indicate at all with the inline offers the binding methods/crypto graphic suites/display metadata.

How is that supposed to work when I'm using inline offers, do these values need to be negotiated upfront/out-of-band? I would like to see a way in the spec to do this. So that credentials_supported becomes publicly available metadata for everyone to resolve, where inline offers are used for more custom credentials / credentials you don't want in your public metadata. Sure you could also add them to the credentials_supported, but then I don't understand what the purpose of the inline offers is.

[paulbastian]

@TimoGlastra what are you referring to with inline offers? That's not a term in the spec?

In my opinion, it is bad to duplicate data and the credential offer should be rather small. Additionally we should aim to limit too much optionality to simplify implementations.

Therefore the credential offer should only refer to the identifier from the metadata. Or am I missing something here?

[nklomp]

Then the whole object vs string for an offer wouldn't make any sense. Simply use ids/scopes and be done with it. Also ensures the QR/link if used by value is smaller.

@Sakurann I do like the fact that scopes can include multiple credentials. But yes IMO using ids makes for an easy implementation that probably will serve a lot of use cases

[Sakurann]

@paulbastian I think what is referred to as inline offer is using format/doctype to specify the credential being offered in the example below from the spec.

   "credentials": [
      "UniversityDegree_JWT",
      {
         "format": "mso_mdoc",
         "doctype": "org.iso.18013.5.1.mDL"
      }
   ]

I think what I am learning from this discussion is that it would be beneficial to change the current offer structure to have the following two options (@TimoGlastra I understand the original issue was about inline offer but I think suggested change also has impact on the credentials param structure itself):

• pass identifier as a string in the credentials Credential Offer parameter so that the wallet can discover the full metadata from credentials_supported array. this will prevent error-prone matching using format/type. when issuer has an entry in the credentials_offer that it wants to offer, this parameter MUST be used. this also means that identifier for each entry in the credentials_supported array becomes mandatory to avoid Paul's concern about duplication.
• pass full credentials_supported entry in the credentials Credential Offer parameter when the issuer wants to offer the issuance of one-off credentials, or credentials it does not want displayed in the public issuer metadata. so there must not be an entry in the credentials_supported array for this credential. Though in this case, I wonder if this credentials_supported entry should be signed however, there might not be such need because the rest of the issuer metadata like endpoints still needs to be discovered from the issuer metadata, so even if attacker wants to put a malicious inline offer, good issuer will not know how to issue it?

please let me know if I misunderstood/mischaracterized the discussion. Our implementation would also be supportive of this approach because we are learning that it is more useful to put identifiers value in the credential offer than scopes value.

so the updated credential offer will look as following:

   "credentials": [
      "university_degree_jwt_computer_science", // matches with `c_identifier` value in the `credentials_supported` metadata entry
      {
        // entire `credentials_supported` entry for that credential that cannot be found from the issuer metadata
          "format": "mso_mdoc",
          "doctype": "org.iso.18013.5.1.mDL",
          "cryptographic_binding_methods_supported": [
              "mso"
          ],
          "cryptographic_suites_supported": [
              "ES256", "ES384", "ES512"
          ],
          "display": [
              {
                  "name": "Mobile Driving License",
                  "locale": "en-US",
                  "logo": {
                      "url": "https://examplestate.com/public/mdl.png",
                      "alt_text": "a square figure of a mobile driving license"
                  },
                  "background_color": "#12107c",
                  "text_color": "#FFFFFF"
              },
              {
                  "name": "在籍証明書",
                  "locale": "ja-JP",
                  "logo": {
                      "url": "https://examplestate.com/public/mdl.png",
                      "alt_text": "大学のロゴ"
                  },
                  "background_color": "#12107c",
                  "text_color": "#FFFFFF"
              }
          ],
          "claims": {
              "org.iso.18013.5.1": {
                  "given_name": {
                      "display": [
                          {
                              "name": "Given Name",
                              "locale": "en-US"
                          },
                          {
                              "name": "名前",
                              "locale": "ja-JP"
                          }
                      ]
                  },
                  "family_name": {
                      "display": [
                          {
                              "name": "Surname",
                              "locale": "en-US"
                          }
                      ]
                  },
                  "birth_date": {}
              },
              "org.iso.18013.5.1.aamva": {
                  "organ_donor": {}
              }
          }
      }
   ]

cc @pmhsfelix

[TimoGlastra]

I think what is referred to as inline offer is using format/doctype to specify the credential being offered in the example below from the spec.

Yes indeed that's what I mean with inline offer. I couldn't find a clear name for it in the spec, so this is how I've started to call it.

(@TimoGlastra I understand the original issue was about inline offer but I think suggested change also has impact on the credentials param structure itself):

The suggestion you listed in the two bullet points @Sakurann sounds like a good solution to me, and would solve my issues. It would also simplify the spec a bit, as the structure for the issuer metadata credentials_supported and the object entries in the credentials array from the offer (inline offers) would be the same, and thus less complexity when adding new formats.