Co-branded cards

[kse-clearhaus]

We are adding the Danish national card schemes Dankort and Forbrugsforeningen
to our EMVCo 3DS offering at 3dsecure.io.
These involve Visa/Dankort co-branded cards.
To support co-branded cards, we need to modify our public API.
My initial requirements are:

a. Avoid breaking existing implementations as much as possible
b. Avoid forcing integrators to make decisions about cobranded cards unless
they need them
c. Make it as elegant as possible

Supporting Dankort/Brugsforeningen cards boils down to two things:

1. Delivering the correct CRD to the requestor
2. Sending the received AReq to the correct Directory server

Options for preauth

These are the possible scenarios I can envision for preauth:
A reasonable assumption here is that the integrator knows which card scheme
they want to do authentication with.

1. Modify to return a list of CRD responses
   • Would break existing integrations
2. Add a separate endpoint using either URL, accept headers or something else,
   that will lead to a list being returned
   • Does not look elegant
3. Require a scheme input to /preauth to determine which CRD the integrator
   is interested in
   • We could have an initial period where no scheme input was required
   • Forces all integrators to actively consider what scheme they are using
4. Partially require a scheme input to /preauth, but only for co-branded
   cards. If no scheme input is present with a Visa/Dankort, the prefer the
   Visa part
   • This preference would avoid breaking current integrations and avoid
     integrators not supporting dankort to consider this
   • This could make e.g. NETS feel like they're being ranked behind Visa.
     This is of course not a matter of preference, but of keeping backwards
     compatibility

Options for auth

These are the possible scenarios I can envision for auth:

1. Require a scheme element in the AReq
   • Rather simple
2. Carry over scheme from preauth
   • This would cause problems for 3RI/APP, where preauth is not a requirement
3. Either carry over scheme from preauth or use the passed scheme parameter.
   • A bit more complex, since preauth isn't mandatory with 3RI or APP device channels
   • Would likely only be optional for BRW device channel

[ct-clearhaus]

Regarding preauth: With versioning, (1) would be just fine. Introduce a new version that returns a list, deprecate the old version, leave some time, remove the old version and 🥳. I think this is quite elegant and simple. Practicing this procedure early isn't bad at all; the client should likely get used to updates nonetheless — because that'll surely come over the coming months/years.

Regarding auth: Again, I vote for the simplest option, namely (1).

[dvaeversted]

From our perspective, we would prefer:

preauth option 4, we always know if it is the Dankort side of a cobranded card we are going to use prior to running the 3DS.

auth either option 2 or 3, would make it much simpler in our integration not having to provide this value twice.

[kse-clearhaus]

I am currently leaning towards

preauth: 4,3,2,1

auth: 3,1,2

WRT CT:

Regarding preauth: With versioning, (1) would be just fine. Introduce a new version that returns a list, deprecate the old version, leave some time, remove the old version and . I think this is quite elegant and simple.

I'm not convinced that this is elegant and simple.

1. The process is going to be quite involved and enforcing it is going to take a while.
   Force everyone to move to a temporary API while deprecating the old
   Replacing the old API with the new one
   Remove the temporary API
   Also: It forces changes
2. The return value would have to be a list, the question is then where the threeDSServerTransID should go.
3. It does not allow us to cache the selected Directory Server from the preauth call, so we don't have to do
   the same lookup in the auth call. Based on the fact that we want to verify that a acctNumber reaches a valid DS.

Practicing this procedure early isn't bad at all; the client should likely get used to updates nonetheless — because that'll surely come over the coming months/years.

Yeah. I'm hoping we can avoid as many breaking changes as possible :) Though I agree that we are early on and creating a breaking change is better now than later.

Regarding auth: Again, I vote for the simplest option, namely (1).

l agree that it's simple. Though if we adopt preauth: 4, 3, then we can reuse the cache lookup saved Directory Server.
It would also be nice that we wouldn't have to force integrators to adapt. Skipping an enforcement period.