Rename "providers" to "presentationRequests" or just "requests"?

[marcoscaceres]

As came up in #71, "providers" might not be the most clear member name to use:

@timcappalli proposed:

dictionary DigitalCredentialRequestOptions {
  sequence<DigitalCredentialsPresentationRequest> presentationRequests;
};

I'd be ok with just "requests" tho, but presentationRequests is also pretty clear.

[samuelgoto]

I'd be ok with just "requests" tho, but presentationRequests is also pretty clear.

I'd prefer something short as requests rather than presentationRequests, since it it is going to go front and center in the API call:

navigator.identity.get({
  digital: {
    presentationRequests: [...],
    requests: [...]
  }
});

[timcappalli]

requests SGTM

[marcoscaceres]

Ok, requests it is... will send a PR soon.

[samuelgoto]

Ok, requests it is... will send a PR soon.

Something that we should ponder on is our tolerance to backwards incompatible changes (like this one) and where to draw a line ... this renaming, specifically, will force us to backwards incompatibles changes and propagate it to others, such as here:

https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#name-request

And here:

https://groups.google.com/a/chromium.org/g/blink-dev/c/ak8HvMr-GR4

I think we are still at a point where we can allow ourselves to make backwards incompatible changes, but they will get increasingly more expensive (so the bar for benefits will raise too) as we go along and we should start thinking how to deal with them.

[marcoscaceres]

yes, I agree. Let's set TPAC as the date... I think we will have enough implementation experience by then.

Mindful also that .identity. will also go away soon hopefully once we fix w3c/webappsec-credential-management#244

[samuelgoto]

Mindful also that .identity. will also go away soon hopefully once we fix w3c/webappsec-credential-management#244

I didn't get the sense that Mozilla was supportive of that change.

[marcoscaceres]

I think we are still discussing? Irrespective of this spec, that change still matters because otherwise the Cred Man spec is open ended.

[marcoscaceres]

@bvandersloot-mozilla, would you mind taking a look at my follow up in the Cred Man issue and see if it makes any sense? I’m still feeling pretty strongly we should have the single entry point, but could be convinced otherwise.

[samuelgoto]

I’m still feeling pretty strongly we should have the single entry point, but could be convinced otherwise.

I expanded a bit where I stand in that thread:

w3c/webappsec-credential-management#244 (comment)