make hei adiscussion point

proposals/arch2020.md

@@ -73,9 +73,6 @@ The payment credential class has these properties:
 * The controlling origin can add, update, and enumerate controlled credentials in either a 1p context or in a payment context within the (3p) in-context display.
 * All origins can access the credential selected by the user (returned through Payment Request).
 
-##### Other requirements
-
-* We would like to support the use cases where a "pay" button for a given payment method is displayed only when the user is ready to pay. The Working Group has addressed this through a hasEnrolledInstrument functionality, but continues to seek better privacy properties. 
 
 #### Payment credential display and selection
 
@@ -88,6 +85,7 @@ Note how the payment method information helps determine what happens next:
 
 For discussion:
 
+* We would like to support the use cases where a "pay" button for a given payment method is displayed only when the user is ready to pay. The Working Group has addressed this through a hasEnrolledInstrument functionality, but continues to seek better privacy properties. 
 * How can we ensure that the unique payment credential identifier is not used to track the user? We note that the identifier only needs to change once it has been used. Can browser ping server periodically to get fresh credentials or rotate identifiers?
 * Does the merchant need to receive all data in the payment credential after selection?
 * Could we have the browser generate the unique payment credential identifier, and add another field for routing it to the origin that controls the payment credential? That could help with privacy concerns.