├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── README.md ├── diagrams ├── index.html ├── token-cryptogram.pml ├── tokenization.png ├── tokenization1.png ├── tokenization3.png ├── tokenized-card.pml └── w3cpayment.pu ├── index.html ├── issuerTokens.png ├── networkTokens.png ├── tokenized_cards.html ├── utils.js └── w3c.json /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 4 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Web Payments Working Group 2 | 3 | Contributions to this repository are intended to become part of Recommendation-track documents governed by the 4 | [W3C Patent Policy](http://www.w3.org/Consortium/Patent-Policy-20040205/) and 5 | [Software and Document License](http://www.w3.org/Consortium/Legal/copyright-software). To make substantive contributions to specifications, you must either participate 6 | in the relevant W3C Working Group or make a non-member patent licensing commitment. 7 | 8 | If you are not the sole contributor to a contribution (pull request), please identify all 9 | contributors in the pull request comment. 10 | 11 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 12 | 13 | ``` 14 | +@github_username 15 | ``` 16 | 17 | If you added a contributor by mistake, you can remove them in a comment with: 18 | 19 | ``` 20 | -@github_username 21 | ``` 22 | 23 | If you are making a pull request on behalf of someone else but you had no part in designing the 24 | feature, you can remove yourself with the above syntax. 25 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors 2 | under the 3 | [W3C Software and Document License](http://www.w3.org/Consortium/Legal/copyright-software). 4 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | 2 | # Tokenized Card Payment 3 | 4 |

Read the Tokenized Card Payment Specification.

5 | 6 | -------------------------------------------------------------------------------- /diagrams/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Diagram index 6 | 7 | 8 |
9 |

Draft flow diagram (From MC and Airbnb)

10 |

Flow diagram

11 |
12 | 13 | 14 | -------------------------------------------------------------------------------- /diagrams/token-cryptogram.pml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 3 | participant "Merchant (or PSP)" as Payee 4 | participant "Browser" as UA 5 | actor "Payer" as Payer 6 | participant "Payment Handler" as PH 7 | participant "TSP" as TSP 8 | 9 | title Subsequent cryptogram request for previous card-on-file token 10 | note over Payer: For merchants who do not have backend integrations to use Payment Request API for subsequent cryptograms. 11 | 12 | 13 | == Checkout == 14 | 15 | Payee->UA: Serve check-out page 16 | UA->Payer: Present check-out page with PR API('token-cryptogram') 17 | UA<-Payer: Push Buy button 18 | note over PH: Open question: narrow matching if payment handler is token requestor; broad matching if payee is token requestor. 19 | alt Skip-the-sheet flow 20 | UA->PH: Launch Payment Handler that matches request filters (tokenReferenceID or PAN, tokenRequestorID) 21 | else Show the sheet flow 22 | UA->Payer: Offer Payment Handler matching request filters (tokenReferenceID or PAN, tokenRequestorID) 23 | UA<-Payer: Select Payment Handler 24 | UA->PH: Launch Payment Handler 25 | end 26 | 27 | note over UA,PH: The payment handler may not require user interaction before fetching the cryptogram. 28 | 29 | == Tokenization == 30 | 31 | note over PH, TSP: Authentication, token caching, payment handler verification, and other payment handler details out of scope. 32 | 33 | PH->TSP: Request data 34 | PH<-TSP: Return cryptogram and other relevant data 35 | UA<-PH: Return 'token-cryptogram' method data 36 | Payee<-UA: Return payment response 37 | 38 | @enduml 39 | -------------------------------------------------------------------------------- /diagrams/tokenization.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/webpayments-methods-tokenization/5e30165364eccba0f80edb77c655d8e3c3789e9e/diagrams/tokenization.png -------------------------------------------------------------------------------- /diagrams/tokenization1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/webpayments-methods-tokenization/5e30165364eccba0f80edb77c655d8e3c3789e9e/diagrams/tokenization1.png -------------------------------------------------------------------------------- /diagrams/tokenization3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/webpayments-methods-tokenization/5e30165364eccba0f80edb77c655d8e3c3789e9e/diagrams/tokenization3.png -------------------------------------------------------------------------------- /diagrams/tokenized-card.pml: -------------------------------------------------------------------------------- 1 | @startuml 2 | 3 | participant "Merchant (or PSP)" as Payee 4 | participant "Browser" as UA 5 | actor "Payer" as Payer 6 | participant "Payment Handler" as PH 7 | participant "TSP" as TSP 8 | 9 | title First request for one-time use, recurring, card-on-file token 10 | 11 | == Checkout == 12 | 13 | Payee->UA: Serve check-out page 14 | UA->Payer: Present check-out page with PR API('tokenized-card' or 'token-reference') 15 | UA<-Payer: Push Buy button 16 | UA->Payer: Offer Payment Handlers matching request filters (supportedNetworks, supportedTypes, usageType) 17 | UA<-Payer: Select Payment Handler 18 | UA->PH: Launch Payment Handler 19 | Payer<-PH: Display cards 20 | Payer->PH: Choose card 21 | 22 | == Tokenization == 23 | 24 | note over PH, TSP: Authentication, token caching, payment handler verification, and other payment handler details out of scope. 25 | 26 | PH->TSP: Request data 27 | PH<-TSP: Return data (token, cryptogram, etc.) 28 | UA<-PH: Return 'tokenized-card' or 'token-reference' method data 29 | Payee<-UA: Return payment response 30 | 31 | @enduml 32 | -------------------------------------------------------------------------------- /diagrams/w3cpayment.pu: -------------------------------------------------------------------------------- 1 | @startuml 2 | autonumber 3 | Participant "Merchant / PSP" as merchant 4 | Participant "Browser" as browser 5 | Participant "User" as user 6 | Participant "Payment Handler" as handler 7 | Participant "Token Service Provider" as tsp 8 | 9 | merchant --> browser : Provide checkout page 10 | browser --> user : Display checkout page 11 | user --> browser : Push buy button, triggering pr.show() 12 | browser --> user : Display handlers 13 | user --> browser: Select handler 14 | browser --> handler: Launch 15 | 16 | == Within the Payment Handler == 17 | handler --> user : Display cards 18 | user --> handler : Select card 19 | handler --> tsp : Request token and other data 20 | note right 21 | Depends on Implementation: 22 | - Communication with key provider 23 | - Management and validation of key 24 | - Generation and encryption of data 25 | end note 26 | tsp --> handler : Return data 27 | handler --> browser : Return TokenizedCardResponse 28 | == End of Payment Handler Control == 29 | browser --> merchant : Return TokenizedCardResponse 30 | == End of Payment Request API == 31 | 32 | @enduml 33 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 7 | 8 | Tokenized Card Payment 9 | 10 | 12 | 13 | 74 | 82 | 83 | 84 |
85 |

86 | This specification defines a Payment Method used by the PaymentRequest 87 | API [[!payment-request]] to support tokenized card payments. 88 |

89 |
90 |
91 |

92 | The working group maintains a list 94 | of all bug reports that the group has not yet addressed. Pull 95 | requests with proposed specification text for outstanding issues are 96 | strongly encouraged. 97 |

98 |
99 |
100 |

101 | Introduction 102 |

103 |

104 | This specification addresses data security in credit or debit card 105 | payments on the Web. 106 |

107 |

108 | When making a card payment, the cardholder shares data with a merchant. 109 | The sahred data has traditionally included the number embossed on the 110 | card (the primary account number or PAN), the card expiry date, 111 | cardholder name, and billing address. 112 |

113 |

114 | There are a variety of ways to share this data: imprinting the card 115 | (physically making use of the embossed numbers on the card), swiping 116 | the card through magnetic stripe reader, providing the data through a 117 | chip or contactless connection, typing it into a Web form, or reading 118 | it aloud over the phone. These approaches differ in their convenience 119 | and security. 120 |

121 |

122 | Most notably, if the PAN is intercepted by a malicious actor (in a 123 | merchant store or through a compromised Web site, for example), this 124 | can lead to fraudulent reuse. The card payment ecosystem has chosen to 125 | combat this risk by reducing the circulation of PANs, and instead 126 | reducing attack vectors through more opaque and controlled data. By 127 | accepting (and possibly storing) tokens instead of the PAN, merchants 128 | can reduce the risk of fraud due to data compromise. This can lower 129 | their costs to receive card payments and their liability for some types 130 | of fraud. 131 |

132 |

133 | EMVCo has published [[!EMVCO-TOKENIZATION]] and related documents that 134 | replace the traditional PAN with a "network token" (as well as 135 | additional data to help limit misuse of each network token). These are 136 | called "network" tokens because card payment networks (e.g., American 137 | Express, China Union Pay, Discover, JCB, Mastercard, and Visa) and 138 | issuing banks offer relevant services. The current document describes 139 | how to connect these service providers to the Payment Request 140 | [[payment-request]] ecosystem so that merchants can request network and 141 | issuer tokens, and users can use payment handlers that request these 142 | tokens from service providers. 143 |

144 |

145 | The network tokenization approach has gained some traction in "card 146 | present" transactions, that is through physical terminals. Indeed, in 147 | regions where merchants have migrated to terminals that accept network 148 | tokens, fraud has tended to move online. This trend is an important 149 | reason why the Web Payments Working Group seeks to increase the 150 | security of card payments on the Web. 151 |

152 |
153 |

154 | Security Benefits of Network Tokenization 155 |

156 |

157 | Network tokenization offers several security benefits: 158 |

159 | 169 |

170 | In addition, the current specification includes mechanisms to further 171 | enhance security through encryption of potentially sensitive data. 172 |

173 |
174 |
175 |

176 | The Network Tokenization Ecosystem 177 |

178 |

179 | In [[!EMVCO-TOKENIZATION]] EMVCo describes the different roles in the 180 | tokenization ecosystem as well as the data requirements that are 181 | related through the current specification. Please consult that 182 | document for authoriative definitions. For the purposes of this 183 | introduction, here are brief descriptions of key roles: 184 |

185 |
186 |
187 | Card Issuer 188 |
189 |
190 | The card issuer is typically a bank that makes available a credit 191 | or debit card to a customer, the cardholder. 192 |
193 |
194 | Token Service Provider (TSP) 195 |
196 |
197 | Token Service Providers perform a variety of tasks, especially the 198 | generation and storage of tokens, mapping between PANs and tokens 199 | (and vice versa), and validating token usage. 200 |
201 |
202 | Token Requestor 203 |
204 |
205 | The Token Requestor is authorized to request tokens from the Token 206 | Service Provider. Different parties may be Token Requestors, 207 | including merchants, parties that have a relationship with a 208 | merchant (e.g., payment gateways), and parties that have 209 | relationships with the user (e.g., payment handlers). 210 |
211 |
212 |
213 |
214 |

215 | Additional Benefits of Network Tokenization 216 |

217 |

218 | Network tokens offer additional benefits as well beyond security: 219 |

220 | 231 |
232 |
233 |
234 |

235 | Examples 236 |

237 |
238 |

239 | Tokenized-Card Request Example 240 |

241 | 
 242 | const methodData = [{
 243 |   supportedMethods: ['tokenized-card'],
 244 |   data: {
 245 |     supportedNetworks: ['mastercard','visa', 'amex', 'discover', 'jcb','unionpay'],
 246 |     supportedTypes: ['credit','debit'],
 247 |     usageType: 'one-time',
 248 |     payeeID: '234987',
 249 |     keyProviderURL: 'https://pspKeyProvider.example/tokenizedCardPublicKey',
 250 |   }
 251 | }];
 252 | 
 253 | const details = {
 254 |   displayItems: [
 255 |     {
 256 |       label: "Sub-total",
 257 |       amount: { currency: "USD", value: "55.00" },
 258 |     },
 259 |     {
 260 |       label: "Sales Tax",
 261 |       amount: { currency: "USD", value: "5.00" },
 262 |     },
 263 |   ],
 264 |   total: {
 265 |     label: "Total due",
 266 |     // The total is USD$65.00 here because we need to
 267 |     // add shipping (below). The selected shipping
 268 |     // costs USD$5.00.  
 269 |     amount: { currency: "USD", value: "65.00" },
 270 |   },
 271 | };
 272 | 
 273 | new PaymentRequest(methodData, details);
 274 |
275 |
276 |
277 |

278 | Tokenized-Card Response Example 279 |

280 |

281 | This example shows some fictitious Mastercard-specific response data. 282 |

283 |
284 | 
 285 |           {
 286 |           displayLast4: "***6789",
 287 |           displayExpiryMonth: "02",
 288 |           displayExpiryYear: "22",
 289 |           displayNetwork: "mastercard",
 290 |           encryptedDetails: "QWxobHZ4bU4yWkt1QUFFU05GWjRHb0FCRkE9PQ==", 
 291 |           }
 292 |
293 |

294 | When decrypted, the encryptedDetails data would be: 295 |

296 | 
 297 |           {
 298 |           cardNumber: "5413339000001513",
 299 |           expiryMonth: "12",
 300 |           expiryYear: "20",
 301 |           cryptogram: "AlhlvxmN2ZKuAAESNFZ4GoABFA==",
 302 |           typeOfCryptogram: "UCAF", // "Universal Card Authentication Field"
 303 |           trid: "59812345678",
 304 |           eci: "242", // Authorization and final transaction request with UCAF data
 305 |           }
 306 |
307 |
308 |
309 |
310 |
311 |

312 | Use Cases and Flows 313 |

314 |

315 | This specification is designed to address these primary use cases: 316 |

317 | 327 |

328 | See the TokenUsageType for more information. 329 |

330 |

331 | For these use cases, the individual payment methods support different 332 | flows: 333 |

334 |
335 |
336 | tokenized-card 337 |
338 |
339 | This payment method covers several flows: 340 |
    341 |
  • One-time usage of a token 342 |
    • 343 |
  • Recurring payments with a token 344 |
    • 345 |
  • Card-on-file use cases with the following assumptions. The 346 | payee seeks a token and does not yet have any card information from 347 | the payer. The response data includes a token, cryptogram, and 348 | other information sufficient for an authorization request. 349 |
    • 350 |
351 |
352 |
353 | token-reference 354 |
355 |
356 | This payment method covers the same flows as 357 | tokenized-card but relies on the payee (or their payment 358 | service provider) having a backend integration to reach a Token 359 | Service Provider. The payee expects to retrieve token, 360 | cryptogram, and other information through backend APIs and therefore 361 | only needs a reference via Payment Request API. In other words, the 362 | existence of the backend integration means the payee requires less 363 | data than with tokenized-card. 364 |
365 |
366 | token-cryptogram 367 |
368 |
369 | This payment method is for card-on-file use cases when the payee (or 370 | their payment service provider) already has a token. The payee only 371 | requires a new cryptogram for a subsequent transaction with the same 372 | token. For this payment method, we assume the payee (or their payment 373 | service provider) does not have a backend integration 374 | that enables them to reach a Token Service Provider for the 375 | cryptogram. Through this payment method, the payee leverages Payment 376 | Request API and the user's Payment Handler to reach the original 377 | Token Service Provider. 378 |
379 |
380 |
381 |
382 |

383 | Assumptions 384 |

385 | 399 |
400 |
401 |

402 | Tokenized-Card Payment Method 403 |

404 |

405 | The payment method identifier string for the Tokenized Card 406 | Payment method is tokenized-card. 407 |

408 |
410 |

411 | TokenizedCardRequest dictionary 412 |

413 |

414 | This section describes payment method specific data that is supplied 415 | as part of the data argument to the PaymentRequest 416 | constructor. 417 |

418 | 
 419 |         dictionary TokenizedCardRequest{
 420 |           sequence<DOMString>       supportedNetworks;
 421 |           sequence<BasicCardType>   supportedTypes;
 422 |           required DOMString              keyProviderURL;
 423 |                    TokenUsageType         usageType;
 424 |                    DOMString              payeeID;
 425 |         };
 426 |
427 |

428 | The TokenizedCardRequest dictionary contains the 429 | following members: 430 |

431 |
432 |
433 | supportedNetworks member 434 |
435 |
436 | A sequence of identifiers for card networks that the payee accepts. 437 | W3C maintains a list of approved 438 | card network identifiers. 439 |
440 |
441 | supportedTypes member 442 |
443 |
444 | A card can be of type "credit", "debit", or "prepaid", as derived 445 | from the issuer identification number (the first eight digits of 446 | the primary account number (PAN). The different types are 447 | represented as the BasicCardType enum. 448 |
449 |
450 | usageType member 451 |
452 |
453 | A payee may request a TokenUsageType. If not present, the 454 | value of this member defaults to "one-time". 455 |
456 |
457 | payeeID member 458 |
459 |
460 | This Member is an optional Payment Network-specific string 461 | that the Token Service Provider may use to constrain the 462 | token for us by a single party. This is called a "merchant 463 | identifier" in the EMVCO Tokenization Specification. 464 |
465 |
466 | keyProviderURL member 467 |
468 |
469 | This member designates, via a URL, a public key trusted by the 470 | Token Service Provider. The source of the key, therefore, 471 | becomes the effective requestor of the tokenized-card from a 472 | Token Service Provider's perspective. 473 |

475 | See What public 477 | key formats are acceptable, and any constraints? #1 . 478 |

479 |
480 |
481 |

482 | For more information about handling of supportedNetworks and 483 | supportedTypes see the steps to check if an instrument is 484 | supported. 485 |

486 |

487 |
488 |
489 |

490 | TokenUsageType enum 491 |

492 | 
 493 |           enum TokenUsageType { "one-time", "card-on-file", "recurring" };
 494 |
495 |
496 |
497 | "one-time" 498 |
499 |
500 | The payee expects to use the token for a single authorization. How 501 | exactly the payee can use the token (e.g., for a charge, an update 502 | to the authorization, a partial refund, a second partial shipment, 503 | or incremental charges) is outside the scope of this specification. 504 |
505 |
506 | "card-on-file" 507 |
508 |
509 | The payee expects to re-use the token for as yet uknown future 510 | transactions, including payer-initiated transactions and 511 | payee-initiated transactions (e.g., for partial shipment, 512 | incremental charges, and resubmission use cases). 513 |
514 |
515 | "recurring" 516 |
517 |
518 | The payee expects to re-use the token exclusively for a recurring 519 | payment according to an agreement with the payer. 520 |
521 |
522 |
523 |
525 |

526 | TokenizedCardResponse dictionary 527 |

528 | 
 529 |         dictionary TokenizedCardResponse {
 530 |                        DOMString       cardholderName;
 531 |                        DOMString       displayMaskedCard;
 532 |                        DOMString       displayLast4;
 533 |            required    DOMString       displayExpiryMonth;
 534 |            required    DOMString       displayExpiryYear; 
 535 |            required    DOMString       displayNetwork;
 536 |                        DOMString       par;
 537 |                        DOMString       tokenReferenceID;
 538 |                        DOMString       eci;
 539 |                        PaymentAddress? billingAddress;
 540 |            required    DOMString       encryptedDetails;
 541 |          };
 542 |
543 |
544 |
545 | cardholderName member 546 |
547 |
548 | The card holder's name as it appears on the card. 549 |
550 |
551 | displayLast4 member 552 |
553 |
554 | It is common for applications to want to display recognizable 555 | information about the user's card, without revealing sensitive 556 | credentials. This value may be used as a hint, for the common case 557 | of displaying the last four digits of the original PAN. 558 |
559 |
560 | displayMaskedCard member 561 |
562 |
563 | In some cases, the card issuer may provide an alternative hint to 564 | displayLast4. Applications MAY use either 565 | displayLast4 or displayMaskedCard as a hint, and 566 | SHOULD use only one of them to avoid confusion or leaking 567 | information. 568 |
569 |
570 | displayExpiryMonth member 571 |
572 |
573 | A two-digit string for the actual expiry month of the card in the 574 | range "01" to "12". 575 |
576 |
577 | displayExpiryYear member 578 |
579 |
580 | A four-digit string for the expiry year of the actual card in the 581 | range "0000" to "9999". 582 |
583 |
584 | displayNetwork member 585 |
586 |
587 | The name of the actual Payment Network of the card. 588 |
589 |
590 | billingAddress member 591 |
592 |
593 | A PaymentAddress that represents the billing address 594 | associated with the card, or null. 595 |
596 |
597 | par member 598 |
599 |
600 | This optional member is a Payment Account Reference (or 601 | PAR), which enables merchants, acquirers and payment 602 | processors to link transactions initiated with affiliated Payment 603 | Tokens to transactions based on the underlying primary account 604 | number. The value is a composite field consisting of 29 605 | uppercase alphanumeric roman characters. See [[EMVCO-TOKENIZATION]] 606 | for more details. 607 |
608 |
609 | tokenReferenceID member 610 |
611 |
612 | This optional member is a Token Reference ID, a substitute 613 | for the cardNumber that does not 615 | expose information about the cardNumber or the 617 | underlying primary account number. It is a Payment 618 | Network-specific string. 619 |
620 |
621 | eci member 622 |
623 |
624 | This optional member is an Electronic Commerce Indicator, a 625 | Payment Network-specific string to indicate the results of 626 | user authentication. For related discussion about authentication, 627 | see [[3ds]]. 628 |
629 |
630 | encryptedDetails member 631 |
632 |
633 | This member is a string that represents 634 | EncryptedTokenizedCard information, encrypted with the 635 | keyProviderURL 636 | according to [[webpayments-crypto]]. 637 |
638 |
639 |
641 |

642 | EncryptedTokenizedCard dictionary 643 |

644 |

645 | This dictionary defines the sensitive data that is to be encrypted. 646 | Note that the fields of this dictionary do not themselves influence 647 | the encryption. 648 |

649 |

652 | 
 653 |           dictionary EncryptedTokenizedCard {
 654 |            required DOMString       cardNumber;
 655 |            required DOMString       expiryMonth;
 656 |            required DOMString       expiryYear;
 657 |            required DOMString       cryptogram;
 658 |            required DOMString       typeOfCryptogram;
 659 |            required DOMString       trid;
 660 |                     DOMString       tokenRequestorKey;
 661 |           };
 662 |
663 |
664 |
665 | cardNumber member 666 |
667 |
668 | This member is a Payment Token. 669 |
670 |
671 | expiryMonth member 672 |
673 |
674 | A two-digit string of dynamic data in the range "01" to "12"; 675 | this does not represent the actual expiry month of the card. 676 |
677 |
678 | expiryYear member 679 |
680 |
681 | A four-digit string of dynamic data in the range "0000" to 682 | "9999"; this does not represent the actual expiry year of the 683 | card. 684 |
685 |
686 | cryptogram member 687 |
688 |
689 | This member is a Token Cryptogram. It is Payment 690 | Network-specific and used to ensure the authenticity of the 691 | transaction. 692 |
693 |
694 | typeOfCryptogram member 695 |
696 |
697 | This member is a Payment Network-specific string that 698 | describes the Token Cryptogram type. 699 |
700 |
701 | trid member 702 |
703 |
704 | This member is a Token Requestor ID, an 11-digit numeric 705 | value that identifies the Token Requestor (e.g., the 706 | payment handler) and is used as part of authorization 707 | flows. 708 |
709 |
710 | tokenRequestorKey member 711 |
712 |
713 | This member is a public key that belongs to the Token 714 | Requestor. It is intended to be used in the 715 | token-cryptogram payment method for card-on-file use 716 | cases. 717 |
718 |
719 |
720 |
721 |
722 |
723 |

724 | Token-Reference Payment Method 725 |

726 |

727 | The payment method identifier string for the Token Reference 728 | Payment method is token-reference. 729 |

730 |

731 |
733 |

734 | TokenReferenceRequest dictionary 735 |

736 |

737 | This section describes payment method specific data that is supplied 738 | as part of the data argument to the PaymentRequest 739 | constructor. 740 |

741 | 
 742 |         dictionary TokenReferenceRequest{
 743 |           sequence<DOMString>       supportedNetworks;
 744 |           sequence<BasicCardType>   supportedTypes;
 745 |                    TokenUsageType         usageType;
 746 |                    DOMString              payeeID;
 747 |         };
 748 |
749 |
750 |
751 | supportedNetworks member 752 |
753 |
754 | A sequence of identifiers for card networks that the payee accepts. 755 | W3C maintains a list of approved 756 | card network identifiers. 757 |
758 |
759 | supportedTypes member 760 |
761 |
762 | A card can be of type "credit", "debit", or "prepaid", as derived 763 | from the issuer identification number (the first eight digits of 764 | the primary account number (PAN). The different types are 765 | represented as the BasicCardType enum. 766 |
767 |
768 | usageType member 769 |
770 |
771 | A payee may request a TokenUsageType. If not present, the 772 | value of this member defaults to "one-time". 773 |
774 |
775 | payeeID member 776 |
777 |
778 | This Member is an optional Payment Network-specific string 779 | that the Token Service Provider may use to constrain the 780 | token for us by a single party. This is called a "merchant 781 | identifier" in the EMVCO Tokenization Specification. 782 |
783 |
784 |
785 |
787 |

788 | TokenReferenceResponse dictionary 789 |

790 | 
 791 |         dictionary TokenReferenceResponse {
 792 |                   required DOMString       tokenReferenceID;
 793 |                   required DOMString       trid;
 794 |                   };
 795 |
796 |
797 |
798 | tokenReferenceID member 799 |
800 |
801 | This member is a Payment Network-specific Token Reference 802 | ID that the payee uses on the backend to retrieve additional 803 | information about the card. 804 |
805 |
806 | trid member 807 |
808 |
809 | This member is a Token Requestor ID, an 11-digit numeric 810 | value that identifies the token requestor (e.g., the payment 811 | handler) and is used as part of authorization flows. 812 |
813 |
814 |
815 |
816 |
817 |

818 | Token-Cryptogram Payment Method 819 |

820 |

821 | The payment method identifier string for the Token Cryptogram 822 | Payment method is token-cryptogram. 823 |

824 |

825 |
827 |

828 | TokenCryptogramRequest dictionary 829 |

830 |

831 | This section describes payment method specific data that is supplied 832 | as part of the data argument to the PaymentRequest 833 | constructor. 834 |

835 | 
 836 |         dictionary TokenCryptogramRequest{
 837 |            required DOMString   tokenRequestorID;
 838 |                     DOMString   tokenReferenceID;
 839 |                     DOMString   encryptedCardNumber;
 840 |         };
 841 |
842 |

843 | The TokenCryptogramRequest dictionary contains the 844 | following members: 845 |

846 |
847 |
848 | tokenReferenceID member 849 |
850 |
851 | This member is a Payment Network-specific Token Reference 852 | ID that represents the stored token for which the payee is 853 | requesting a new cryptogram. 854 |
855 |
856 | encryptedCardNumber member 857 |
858 |
859 | This optional member is an encrypted Payment Token. Although 860 | the tokenReferenceID is preferred it may not always be 861 | available, in which case the payee may provide this Payment 862 | Token instead, encrypted with the tokenRequestorKey, for example that 864 | was returned through the tokenized-card payment 865 | response. 866 |

867 | Need more details on encryption. 868 |

869 |
870 |
871 | tokenRequestorID member 872 |
873 |
874 | This member identifies the payment handler used to request the 875 | original token. It is an 11-digit numeric value that is a Token 876 | Requestor ID. The user agent uses this information to provide a 877 | path to the Token Service Provider through the payment 878 | handler that requested the original token. It is assumed that the 879 | payment handler also has a means to validate that the payee 880 | requesting the cryptogram is authorized to do so. 881 |
882 |
883 |
884 |
886 |

887 | TokenCryptogramResponse dictionary 888 |

889 | 
 890 |           dictionary TokenCryptogramResponse{
 891 |                required DOMString cryptogram;
 892 |                required DOMString typeOfCryptogram;
 893 |                         DOMString eci;
 894 |           };
 895 |
896 |
897 |
898 | cryptogram member 899 |
900 |
901 | This member is a Token Cryptogram. 902 |
903 |
904 | typeOfCryptogram member 905 |
906 |
907 | This member is a Payment Network-specific string that 908 | describes the Token Cryptogram type. 909 |
910 |
911 | eci member 912 |
913 |
914 | This optional member is an Electronic Commerce Indicator, a 915 | Payment Network-specific string to indicate the results of 916 | user authentication. For related discussion about authentication, 917 | see [[3ds]]. 918 |
919 |
920 |
921 |
922 |
923 |

924 | Interfacing with a payment request for tokenized-card 925 |

926 |

927 | Currently these sections are for the tokenized-card 928 | payment method; we will need similar algorithms for other payment 929 | methods. 930 |

931 |
932 |

933 | Steps to check if a payment can be made 934 |

935 |

936 | The steps to check if a payment can be made by a Payment 937 | Handler that handles "tokenized-card" takes 938 | TokenizedCardRequest request as input. It returns 939 | either true or false: 940 |

941 |
    942 |
  1. Let cards be a list of 943 | cards associated with this payment handler. 944 |
    2. 945 |
  2. If cards is 946 | empty, return false. 947 |
    3. 948 |
  3. Let networks be an empty DOMString sequence. 950 |
    4. 951 |
  4. Let types be an empty BasicCardType sequence. 952 |
    5. 953 |
  5. Let cryptograms be an empty DOMString sequence. 955 |
    6. 956 |
  6. Let usage be the value of 957 | request["usageType"] if present, otherwise set it to 958 | "one-time". If the value of usage is not a legal value of 959 | TokenUsageType, set usage to "one-time". 960 |
    7. 961 |
  7. If request["supportedTypes"] is present, append each 962 | item in request["supportedTypes"] to types. 963 |
    8. 964 |
  8. If request["supportedNetworks"] is present, append 965 | each item in request["supportedNetworks"] to 966 | networks. 967 |
    9. 968 |
  9. For each card in cards: 969 |
      970 |
    1. Let isSupported be the result of running the 971 | steps to check if an instrument is supported, passing in 972 | card, networks, types, 973 | cryptograms, usage 974 |
      2. 975 |
    2. If isSupported is true, then return true. 976 |
      3. 977 |
    978 |
    10. 979 |
  10. Return false. 980 |
    11. 981 |
982 |
983 |
984 |

985 | Steps to check if an instrument is supported 986 |

987 |

988 | The steps to check if an instrument is supported takes as 989 | input a card card, a list of type types, a 991 | list of network 992 | networks, and a usageType usage. It returns 994 | true if the card is supported, false otherwise. 995 |

996 |
    997 |
  1. If types is 998 | empty and networks is empty and cryptograms 1000 | is empty, return true. 1001 |
    2. 1002 |
  2. If networks is not 1003 | empty: 1004 |
      1005 |
    1. If networks does not include the card's 1006 | network, return false. 1007 |
      2. 1008 |
    1009 |
    3. 1010 |
  3. If types is not 1011 | empty: 1012 |
      1013 |
    1. If types does not include the card's 1014 | type, return false. 1015 |
      2. 1016 |
    1017 |
    4. 1018 |
  4. If cryptograms is 1019 | not empty: 1020 |
      1021 |
    1. If cryptograms does not include one of the 1022 | supportedTypes of the 1023 | payment handler, return false. 1024 |
      2. 1025 |
    1026 |
    5. 1027 |
  5. If usage is not supported by the payment 1028 | handler, return false. 1029 |
    6. 1030 |
  6. Return true. 1031 |
    7. 1032 |
1033 |
1034 |
1035 |

1036 | Steps to respond to a payment request 1037 |

1038 |

1039 | The steps to respond to a payment request are given by the 1040 | following algorithm. If the end user inputs or selects a card 1041 | that meets the constraints of TokenizedCardRequest 1042 | data, the algorithm returns a card as a 1043 | TokenizedCardResponse. 1044 |

1045 |
    1046 |
  1. Let networks be 1047 | data["supportedNetworks"], or an empty list if 1048 | data["supportedNetworks"] is missing. 1049 |
    2. 1050 |
  2. Let types be 1051 | data["supportedTypes"], or an empty list if 1052 | data["supportedTypes"] is missing. 1053 |
    3. 1054 |
  3. Let key be the 1055 | result of fetching data["keyProviderURL"]. In case 1056 | of an error, throw throw an error abort these steps. 1057 |
    4. 1058 |
  4. Let card be a TokenizedCardResponse. 1059 |
    5. 1060 |
  5. Set card["cardholderName"] to the card 1061 | holder's name, or the empty string if the user chooses not to 1062 | provide it. 1063 |
    6. 1064 |
  6. To provide a hint to help the user select this card, 1065 | either set card["displayLast4"] to a string that 1066 | includes the last four digits of the primary account number 1067 | (e.g., "*** 5050") or set card["displayMaskedCard"] 1068 | to a string that represents different non-sensitive information about 1069 | the card (e.g., "Francine Business"). 1070 |
    7. 1071 |
  7. Set card["displayExpiryMonth"] to two-digit 1072 | string ranging from "01" to "12", or the 1073 | empty string if the user chooses not to provide it or the type 1074 | doesn't require an expiry month. 1075 |
    8. 1076 |
  8. Set card["displayExpiryYear"] to a four-digit 1077 | string in the range "0000" to "9999", or 1078 | the empty string if the user chooses not to provide it or the 1079 | type doesn't require an expiry year. 1080 |
    9. 1081 |
  9. Set card["displayNetwork"] to a string that 1082 | identifies the card network. 1083 |
    10. 1084 |
  10. Set card["par"] to a 29-character string, or 1085 | the empty string if not available. 1086 |
    11. 1087 |
  11. Set card["tokenReferenceID"] to a Token 1088 | Reference ID string, or the empty string if not available. 1089 |
    12. 1090 |
  12. If a billing address is not required for this card type, 1091 | then set card["billingAddress"] to null. Otherwise: 1092 |
      1093 |
    1. Let redactList be « "phone" ». 1094 |
      2. 1095 |
    2. Let billingAddress be the result running the steps 1096 | to create a 1098 | PaymentAddress from user-provided input with 1099 | redactList. 1100 |
      3. 1101 |
    3. Set card["billingAddress"] to 1102 | billingAddress. 1103 |
      4. 1104 |
    1105 |
    13. 1106 |
  13. Set cardNumber to a tokenized representation of 1107 | primary account number, a string of digits that ranges from 10 1108 | to 19 digits. 1109 |
    14. 1110 |
  14. Set expiryYear to two-digit string ranging from 1111 | "01" to "12", or the empty string if the 1112 | user chooses not to provide it or the type doesn't require an 1113 | expiry month. 1114 |
    15. 1115 |
  15. Set expiryMonth to a four-digit string in the range 1116 | "0000" to "9999", or the empty string if 1117 | the user chooses not to provide it or the type doesn't require 1118 | an expiry year. 1119 |
    16. 1120 |
  16. Set cryptogram to a Token Cryptogram, a 1121 | Payment Network-specific string. 1122 |
    17. 1123 |
  17. Set typeOfcryptogram to a Payment 1124 | Network-specific string that represents the type of the 1125 | cryptogram. 1126 |
    18. 1127 |
  18. Set trid to a Token Requestor ID, an 11-digit 1128 | numeric value. 1129 |
    19. 1130 |
  19. Set eci to Electronic Commerce Indicator, a 1131 | Payment Network-specific string. 1132 |
    20. 1133 |
  20. Set card["encryptedDetails"] to a string 1134 | following the steps for response data encryption, where the 1135 | content encryption key is set to key and the 1136 | plaintext encryption algorithm takes as input 1137 | cardNumber, expiryMonth, expiryYear, 1138 | cryptogram, typeOfcryptogram, trid, 1139 | and eci. 1140 |
    21. 1141 |
  21. Return card. 1142 |
    22. 1143 |
1144 |

1145 | Until such time as we learn of intention by browsers/mediators to 1146 | implement this specification, we have eliminated discussion of 1147 | validation in this algorithm. 1148 |

1149 |

1150 |
1151 |
1152 |
1153 |

1154 | There is only one class of product that can claim conformance to this 1155 | specification: a payment handler. 1156 |

1157 |

1158 | A conforming payment handler MUST: 1159 |

1160 | 1172 |
1173 |
1174 |

1175 | Security and Privacy Considerations 1176 |

1177 |

1178 |
1179 |
1180 |

1181 | Dependencies 1182 |

1183 |

1184 | This specification relies on several other underlying specifications. 1185 |

1186 |
1187 |
1188 | Payment Request API 1189 |
1190 |
1191 | The terms PaymentAddress and PaymentRequest 1192 | constructor are defined in Payment Request API 1193 | [[payment-request]]. 1194 |
1195 |
1196 | Payment Method Identifiers 1197 |
1198 |
1199 | The term payment method 1200 | identifier and standardized payment method 1201 | identifier are defined by the Payment Method Identifier 1202 | specification [[!payment-method-id]]. 1203 |
1204 |
1205 | Basic Card Payment 1206 |
1207 |
1208 | The terms basic-card, 1210 | BasicCardType, 1212 | cards, type, networks, 1216 | primary-account-number, 1218 | billing 1219 | address, and card holder's 1221 | name are defined in [[!payment-method-basic-card]]. 1222 |
1223 |
1224 | EMVCo Tokenisation 1225 |
1226 |
1227 | The terms Payment Token, 1228 | Token Cryptogram, 1229 | Payment 1230 | Networks, Token Service Providers, Token Requestor ID, Token Requestor, Merchant Identifier and Tokenized Payment Method Credentials, 1236 | Token Reference ID, and 1237 | Payment Account Reference 1238 | are defined in [[EMVCO-TOKENIZATION]]. 1239 |
1240 |
1241 | EMVCo 3-D Secure 1242 |
1243 |
1244 | The terms Electronic Commerce 1245 | Indicator is defined in [[EMVCO-3DS]]. 1246 |
1247 |
1248 | Payment Method Encryption 1249 |
1250 |
1251 | The steps for response data encryption are described in 1252 | [[!webpayments-crypto]]. That specification defines the terms 1253 | content encryption 1254 | key, message 1255 | structure, and plaintext 1257 | encryption. 1258 |
1259 |
1260 | RFC6454 1261 |
1262 |
1263 | The term origin is defined in [[!RFC6454]]. 1264 |
1265 |
1266 | ISO7812-1 1267 |
1268 |
1269 | ISO 7812-1 specifies a numbering system for the identification of the 1270 | card issuers, the format of the issuer identification number (IIN) 1271 | and the primary account number 1272 | (PAN). 1273 |
1274 |
1275 |
1276 |
1277 |

1278 | Appendix: Token Service Provider Considerations 1279 |

1280 |

1281 | The following Token Service Provider considerations are 1282 | explicitly out of scope for this specification. 1283 |

1284 | 1294 |

1295 |

1296 |
1297 |
1298 |

1299 | Appendix: Flow Diagrams 1300 |

1301 |
1302 |

1303 | First request for one-time use, recurring, card-on-file token 1304 |

1305 |

1306 | This diagram illustrates one flow where a payee requests a token (or 1307 | token reference id) for one-time use, recurring, or card-on-file. 1308 |

1309 |
1310 | 1312 | Tokenized-card and tokenized-reference flows 1314 |
1315 |
1316 |
1317 |

1318 | Subsequent cryptogram request for previous card-on-file token 1319 |

1320 |

1321 | This diagram illustrates a request for a subsequent cryptogram based 1322 | on a previously stored token. 1323 |

1324 |
1325 | 1327 | Token-cryptogram flow 1329 |
1330 |
1331 |
1332 |
1333 |

1334 | Acknowledgments 1335 |

1336 |

1337 | Thanks to Manash Bhattacharjee for his early work on this 1338 | specification. 1339 |

1340 |
1341 | 1342 | 1343 | -------------------------------------------------------------------------------- /issuerTokens.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/webpayments-methods-tokenization/5e30165364eccba0f80edb77c655d8e3c3789e9e/issuerTokens.png -------------------------------------------------------------------------------- /networkTokens.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/w3c/webpayments-methods-tokenization/5e30165364eccba0f80edb77c655d8e3c3789e9e/networkTokens.png -------------------------------------------------------------------------------- /tokenized_cards.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | Tokenized Card Payment 5 | 6 | 8 | 57 | 65 | 66 | 67 |
68 |

69 | The Tokenized Card Payment specification describes the data formats used by the 70 | PaymentRequest API [[!PAYMENTREQUESTAPI]] to support payment by tokenized payment cards. 71 |

72 |
73 | 74 |
75 |

76 | The working group maintains a 77 | list of all bug reports that the group has not yet addressed. 78 | Pull requests with proposed specification text for outstanding issues are strongly encouraged. 79 |

80 |
81 |

Sending comments on this document

82 |

If you wish to make comments regarding this document, please raise them as 83 | GitHub issues. 84 | Only send comments by email if you are unable to raise issues on GitHub (see 85 | links below). All comments are welcome.

86 |
87 |
88 | 89 |
90 |

Introduction

91 |

92 | This specification is a Payment Transaction Message Specification used by the PaymentRequest API 93 | [[!PAYMENTREQUESTAPI]] to support payment by tokenized payment cards.

94 | 95 |

Tokenization provides some advantages over traditional card payments - tokenized credentials are often narrowly scoped, for example single-use or merchant/amount/time scoped. Tokenized credentials also help alleviate some concerns about merchant data breaches since the merchant does not have the raw PAN. This provides some additional security for a consumer. 96 |

97 |
98 | 99 |
100 |

Dependencies

101 |

102 | This specification relies on several other underlying specifications. 103 |

104 |
105 |
Basic Card Payment
106 |
The term BasicCardResponse is defined by the Basic Card Payment specification [[!BASICCARD]].
107 |
Payment Request API
108 |
The term PaymentRequest constructor is defined by the PaymentRequest API 109 | specification [[!PAYMENTREQUESTAPI]].
110 |
Payment Method Identifiers
111 |
The term Payment 112 | Method Identifier is defined by the Payment Method Identifiers specification 113 | [[!METHODIDENTIFIERS]].
114 |
Web IDL
115 |
The IDL in this specification is defined by Web IDL [[!WEBIDL]].
116 |
117 |
118 | 119 |
120 |

Payment Method Identifier

121 |

The payment method identifier string for the Tokenized Card Payment method is card-token.

122 |
123 | 124 |
125 |

Payment Method Specific Data for the PaymentRequest constructor

126 |

This section describes payment method specific data that is supplied as part of the data 127 | argument to the PaymentRequest constructor. This specification extends the BasicCardRequest (defined in [[!BASICCARD]]) with some additional fields required for tokenization.

128 |
129 |

TokenCardRequest

130 | 
131 |         enum TokenCardType { "emv", "issuer" };
132 | 
133 |         dictionary TokenCardRequest : BasicCardRequest {
134 |           sequence<TokenCardType> supportedTokenTypes;
135 |         };
136 |
137 | 138 |

139 | The TokenCardRequest dictionary contains the following fields: 140 |

141 | 142 |
143 |
supportedTokenTypes
144 |
The supportedTokenTypes field contains a sequence of token card types that the merchant 145 | accepts. The values mean the following: 146 |
    147 |
  • "emv": These are tokens (typically single-use) provided by card networks (cf. supportedNetworks) that represent the underlying PAN.
    • 148 |
  • "issuer": With these tokens, a provider serves as a card issuer by generating a new card number. This new card number is backed by the original PAN or by another funding source. During charging of these tokens, the provider translates the generated card number back into the original PAN or original funding source.
    • 149 |
150 |
151 |

A payment service may wish to use emv tokens if its infrastructure supports sending a token/cryptogram combination. Issuer tokens may be preferred in cases where the card is not emv-tokenizable or if the merchant is unable to handle emv tokens.

152 | 153 |

The supportedNetworks and supportedTypes fields are both optional. 154 | If neither is provided then any card may be returned. If supportedNetworks 155 | is provided then any card that matches one of the supported networks is returned. 156 | If supportedTypes is provided then any card that matches one of the supported types is returned.

157 | 158 |

Implementations will determine how to match values of supportedTypes.

159 | 160 |

161 | This specification covers a limited number of supportedTokens. There are other types of tokens such as gateway tokens, but because they involve substantially different flows of information (e.g., merchant onboarding), this specification does not cover them.

162 |
163 |
164 | 165 |
166 |

Payment Method Response

167 |

168 | The TokenizedCardResponse dictionary contains the response from the PaymentRequest API when a user accepts payment with a Tokenized Payment Card payment method. This specification extends the BasicCardResponse (defined in [[!BASICCARD]]) with some additional fields required for tokenization. It should be noted that the "cardSecurityCode" from the BasicCardResponse will contain a card security code for issuer-based tokens, but will contain the cryptogram for network tokens. The combination of cardNumber (the token number) + cardSecurityCode (either cryptogram or security code - note that security code can be 3 or 4 digits) establishes a one-time use credential. 169 |

170 | 171 | 
172 |         dictionary TokenizedCardResponse: BasicCardResponse {
173 |             required DOMString          cardLast4;
174 |             DOMString          tokenType;
175 |             DOMString        tokenRequesterId;
176 |         };
177 |
178 | 179 |

180 | The TokenizedCardResponse dictionary contains the following fields: 181 |

182 | 183 |
184 |
cardLast4
185 |
The cardLast4 field contains the last 4 digits of the original (non-token) primary account number (PAN) for the payment card. This may be used for display purposes during the purchase.
186 |
tokenType
187 |
The tokenType field contains the token type selected by the user. This is one of the values of supportedTypes.
188 |
tokenRequesterId
189 |
The tokenRequesterId field contains ID of the entity that requested the token from the network (likely the creator of the payment app). This field is only applicable when tokenType is "emv".
190 |
191 |
192 | 193 |
194 |

Example request/responses

195 | 196 |
197 |

emv Request/Response

198 | 218 |
219 | 220 |
221 |

issuer Request/Response

222 | 241 |
242 |
243 | 244 | 245 | 246 | 247 | 248 | 249 |
250 |

Appendix: Flow Diagrams

251 | 252 |
253 |

Issuer Token Flow

254 |

issuer token flow

255 |
256 | 257 |
258 |

Network Token Flow

259 |

network token flow

260 |
261 |
262 | 263 | 264 | 265 | -------------------------------------------------------------------------------- /utils.js: -------------------------------------------------------------------------------- 1 | // We should be able to remove terms that are not actually 2 | // referenced from the common definitions 3 | // 4 | // the termlist is in a block of class "termlist", so make sure that 5 | // has an ID and put that ID into the termLists array so we can 6 | // interrogate all of the included termlists later. 7 | var termNames = [] ; 8 | var termLists = [] ; 9 | var termsReferencedByTerms = [] ; 10 | 11 | function restrictReferences(utils, content) { 12 | var base = document.createElement("div"); 13 | base.innerHTML = content; 14 | 15 | // New new logic: 16 | // 17 | // 1. build a list of all term-internal references 18 | // 2. When ready to process, for each reference INTO the terms, 19 | // remove any terms they reference from the termNames array too. 20 | $.each(base.querySelectorAll("dfn"), function(i, item) { 21 | var $t = $(item) ; 22 | var titles = $t.getDfnTitles(); 23 | var n = $t.makeID("dfn", titles[0]); 24 | if (n) { 25 | termNames[n] = $t.parent() ; 26 | } 27 | }); 28 | 29 | var $container = $(".termlist",base) ; 30 | var containerID = $container.makeID("", "terms") ; 31 | termLists.push(containerID) ; 32 | 33 | // add a handler to come in after all the definitions are resolved 34 | // 35 | // New logic: If the reference is within a 'dl' element of 36 | // class 'termlist', and if the target of that reference is 37 | // also within a 'dl' element of class 'termlist', then 38 | // consider it an internal reference and ignore it. 39 | 40 | return (base.innerHTML); 41 | } 42 | 43 | require(["core/pubsubhub"], function(respecEvents) { 44 | "use strict"; 45 | respecEvents.sub('end', function(message) { 46 | if (message == 'core/link-to-dfn') { 47 | // all definitions are linked; find any internal references 48 | $(".termlist a.internalDFN").each(function() { 49 | var $r = $(this); 50 | var id = $r.attr('href'); 51 | var idref = id.replace(/^#/,"") ; 52 | if (termNames[idref]) { 53 | // this is a reference to another term 54 | // what is the idref of THIS term? 55 | var $def = $r.closest('dd') ; 56 | if ($def.length) { 57 | var $p = $def.prev('dt').find('dfn') ; 58 | var tid = $p.attr('id') ; 59 | if (tid) { 60 | if (termsReferencedByTerms[tid]) { 61 | termsReferencedByTerms[tid].push(idref); 62 | } else { 63 | termsReferencedByTerms[tid] = [] ; 64 | termsReferencedByTerms[tid].push(idref); 65 | } 66 | } 67 | } 68 | } 69 | }) ; 70 | 71 | // clearRefs is recursive. Walk down the tree of 72 | // references to ensure that all references are resolved. 73 | var clearRefs = function(theTerm) { 74 | if ( termsReferencedByTerms[theTerm] ) { 75 | $.each(termsReferencedByTerms[theTerm], function(i, item) { 76 | if (termNames[item]) { 77 | delete termNames[item]; 78 | clearRefs(item); 79 | } 80 | }); 81 | } 82 | // make sure this term doesn't get removed 83 | if (termNames[theTerm]) { 84 | delete termNames[theTerm]; 85 | } 86 | }; 87 | 88 | // now termsReferencedByTerms has ALL terms that 89 | // reference other terms, and a list of the 90 | // terms that they reference 91 | $("a.internalDFN").each(function () { 92 | var $item = $(this) ; 93 | var t = $item.attr('href'); 94 | var r = t.replace(/^#/,"") ; 95 | // if the item is outside the term list 96 | if ( ! $item.closest('dl.termlist').length ) { 97 | clearRefs(r); 98 | } 99 | }); 100 | 101 | // delete any terms that were not referenced. 102 | Object.keys(termNames).forEach(function(term) { 103 | var $p = $("#"+term) ; 104 | if ($p) { 105 | var tList = $p.getDfnTitles(); 106 | $p.parent().next().remove(); 107 | $p.remove() ; 108 | tList.forEach(function( item ) { 109 | if (respecConfig.definitionMap[item]) { 110 | delete respecConfig.definitionMap[item]; 111 | } 112 | }); 113 | } 114 | }); 115 | } 116 | }); 117 | }); 118 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": ["83744"] 3 | , "contacts": ["ianbjacobs"] 4 | , "shortName": "webpayments-methods-tokenization" 5 | , "repo-type": "others" 6 | , "exposed": false 7 | } 8 | --------------------------------------------------------------------------------