- From: Ian Jacobs <ij@w3.org>
- Date: Mon, 17 May 2021 16:07:00 -0500
- To: Gerhard Oosthuizen <goosthuizen@entersekt.com>, Stephen McGruer <smcgruer@google.com>, "Blachowicz, Tomasz" <Tomasz.Blachowicz@mastercard.com>, Erhard Brand <erhard@entersekt.com>
- Cc: Web Payments Working Group <public-payments-wg@w3.org>
Hi Gerhard, Stephen, Erhard, Tomasz (and Working Group participants),
Based on reviews of the SPC requirements document [1] and today’s discussion I’ve done some editing to that document and the scope document [2] (which has some definitions). My goal was to address issue 13 (on cardinality [3]) without limiting many-to-many use cases.
Changes to two definitions in the scope document:
* SPC Credential. Data that represents the association between an instrument and an authentication credential. Note: Note: Management of multiple relationships is an implementation detail (e.g., multiple authentications corresponding to a single instrument, or multiple instruments enrolled for a given authentication).
* SPC Credential Identifiers. Each SPC Credential Identifier refers to one SPC Credential. These identifiers are generated during enrollment and stored by the Relying Party in association with an instrument. An instrument may be addressable by more than one SPC Credential Identifier (e.g., when the user has authenticated through different devices for that instrument).
Changes in requirements document:
* Under Enrollment: It must be possible to enroll multiple instruments for a single authentication. Each resulting SPC Credential (that is: each instrument/authentication credential binding) must be independently addressable.
(And deleted: "If the protocol supports more than one instrument per authentication (e.g., within the same SPC Credential), then each instrument must be uniquely addressable and have unique display information.”
* Under Instrument Information: Enrollment of an instrument must include display information for it.
Regarding enrollment of N instruments with a single authentication, the requirements allow for different implementation approaches:
1) N SPC Credentials, each one with the same (for example) FIDO credential information but with distinct instrument information and a unique SPC Credential ID.
2) 1 blob associated with the authentication data, and an associated list of instrument structures, each with a unique SPC Credential ID and instrument information.
The above definitions and requirements also intend to enable different implementations for “N authenticators known to this browser for the same instrument”. For example, one implementation would be “N SPC Credentials, each with a unique SPC Credential Identifier, but all with the same instrument information.”
The issue of “out of band authentication” [4] is not directly addressed through these changes.
I look forward to your comments,
Ian
[1] https://github.com/w3c/secure-payment-confirmation/blob/gh-pages/requirements.md
[2] https://github.com/w3c/secure-payment-confirmation/blob/gh-pages/scope.md
[3] https://github.com/w3c/secure-payment-confirmation/issues/13
[4] https://github.com/w3c/secure-payment-confirmation/issues/30
--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447
Received on Monday, 17 May 2021 21:07:18 UTC