Should a Payment Request API have shipping address APIs? about webpayments

[zkoch]

Should the payment request API have shipping address APIs?

Yes (but that is probably not surprising). Physical good purchases are the majority of online transactions, and part of that flow is the collection of shipping information. Shipping information is special because, unlike loyalty cards, etc, it is impossible to fulfill the transaction without it. It is both ubiquitous and critical across all physical good transactions.

In addition, one of our intended benefits is the reduction of shopping cart abandonment. Improving the final step of a 4-5 step cumbersome checkout flow is not ultimately all that useful. You have to go earlier in the funnel as well.

So to re-iterate, I don't view shipping address and things like loyalty cards, over 18, etc in the same league. Billing address, at least in our proposal, comes from the payment method. If the Credentials CG or the Verifiable Claims TF produces a spec that is usable and is something we want, we can find a way to request additional information at a later date.

[zkoch]

How does this feature reduce shopping cart abandonment?

I tried to address that in the sentence following the one you quoted. Much of abandonment, at least on mobile, happens long before the user arrives at the point of collecting payment information (coming from our research). So to improve only the final step doesn't go far enough.

For shipping address, we have requestAutocomplete already, why aren't we depending on that?

I suspect you're confusing things. requestAutocomplete was a solution geared towards improving payments in the browser. Shipping was just one component of that. Perhaps you mean autofill? And we could, but this relies on users still knowing that autofill is enabled before dropping off the checkout flow (which they don't, and they drop off). Also, rAc isn't widely supported and will probably be deprecated in favor of whatever payments API emerges from this.

To be clear, I don't think that anyone is arguing that shipping information is not important. We do want to automate the collection of it. That said, we don't want to automate it in a way that incurs technical debt in the Web Platform.

I disagree that this is technical debt, because I don't see shipping addresses and things like loyalty cards as being in the same category. So I think we can standardize shipping, which again, is ubiquitous to all physical good transactions, and later standardize other assertions or things like loyalty cards.

[msporny]

Should the payment request API have shipping address APIs?

No, it should not for at least the following reasons:

1. There are other pieces of data that may be important to a payment request (billing address, drop shipping address, pickup address, over 18, loyalty card, subscriber number, etc.). I assume we are not going to add APIs to the payment request API for all of those pieces of information. This problem should be solved in a more generalized way (and that mechanism is the focus of the Verifiable Claims Task Force and the Credentials CG). We shouldn't make a special exception for shipping address.
2. 80% of the state information in the paymentRequest API is dedicated to shipping address. We could greatly reduce the state information by just removing this one feature.

[dlongley]

I'm +1 on removing shipping address from this API.

Let's take this in baby steps, leaving the shipping address collection details up to the merchants for now (as it is today). I agree that we may want a more generalized solution (and standard API) for collecting ancillary information that is related to the payment but not necessarily core to it. A generalized mechanism could potentially be reused for other use cases as well. Because we aren't yet sure how this will look, let's not build something that could potentially be wrong now just for one particular use case, even if it is a common one. We could briefly discuss a future path forward to ensure we won't box ourselves out, but I don't think we should deal with this now.

[adrianhopebailie]

Related to: https://github.com/WICG/paymentrequest/issues/28

👍 for a more generalized method for exchanging data between payee application (website) and payment app outside of the payment request and response messages. But, I'd like to establish if this is a firm requirement for the API before we define the way it is done.

The only use case I can think of that requires this is when the data exchanged alters the parameters of the payment so that the payee needs to update the payment request. In this case, setting a shipping address changes the shipping cost which in turn changes the amount.

Are there use cases beyond shipping where the payee may need the ability to update the payment request before the payment app responds?

[ianbjacobs]

@zkoch, how easily can the "shipping address" approach in your spec be extended to the exchange of other types of data (related to your "later date" comment)?

Ian

[zkoch]

@ianbjacobs I don't think we would extend the current way we handle shipping. I think shipping should be handled separately. I can, however, see us handling additional "assertions" in some standard way at a later date (e.g. over 21, etc). I'm not sure what that would look like right now, as I don't have a good mental model for how to think about those. That's why I was saying if/when the VF TF comes up with something, we should look at that and figure out if it makes sense and how it makes sense.

[msporny]

I don't think we would extend the current way we handle shipping.

This is concerning to me. Building features into the Web Platform that we know are short-term point solutions (like a special API for collecting shipping address) creates technical debt in the Web Platform.

If we want a more standard way of handling assertions like shipping address, which I assert is not special wrt. other types of credentials collected during the payment flow, then we should understand what the mechanism looks like before we standardize on an ersatz version of it.

I'm not sure what that would look like right now, as I don't have a good mental model for how to think about those.

Others, namely many of the participants in the VCTF, have been looking at this problem for a while now do have a more developed mental model of how this stuff should work. We haven't been able to discuss it in the WPWG yet because the discussion keeps being corralled into the VCTF work, but there are a set of proposals that have been discussed/worked on for multiple years now (Credential Management API from Google being one of them) as well as working code that demonstrates an alternative.

... but going back to Adrian's request:

"I'd like to establish if this is a firm requirement for the API before we define the way it is done."

I'd assert that gathering the shipping address isn't a firm requirement for the web payments browser API in Phase I for at least the following reasons:

1. We have a disagreement on the best way to do it, and at least two other groups working on this problem (WebAppSec and VCTF).
2. For shipping address, we have requestAutocomplete already, why aren't we depending on that?
3. At the very worst, we can always add it in Phase II.

[msporny]

Physical good purchases are the majority of online transactions, and part of that flow is the collection of shipping information. Shipping information is special because, unlike loyalty cards, etc, it is impossible to fulfill the transaction without it. It is both ubiquitous and critical across all physical good transactions.

To be clear, I don't think that anyone is arguing that shipping information is not important. We do want to automate the collection of it. That said, we don't want to automate it in a way that incurs technical debt in the Web Platform. Once you add a questionable feature to the Web, it's very hard to <marquee>remove it</marquee>.

[msporny]

In addition, one of our intended benefits is the reduction of shopping cart abandonment.

How does this feature reduce shopping cart abandonment?

[adrianhopebailie]

There are two issue here I think, correct me if I'm wrong.

1. We need a way to get the buyer's shipping address so that the merchant can determine things like the cost of shipping options
2. We need the ability to dynamically change the terms of the offer (total price in this case) based on some user input (selection of a shipping option in this case)

The first issue is the one we should be dealing with here as that is what the issue title says: "Should a Payment Request API have shipping address APIs?"

I am 👍 for gathering of shipping data being separated from the payment request. By the time we request a payment we should at a minimum already know the shipping address so we can provide shipping options in the request.

The UA could make the UI for this very slick by gathering the address data and then using the same dialogue to get the user's payment app selection:

    navigator.payments.addEventListener("optionsChange", function (changeEvent) {
        if(changeEvent.optionGroup == "shipping")
        {
            // Process shipping options change and update amounts

        }
    });

    navigator.credentials.get({
        "type": "shippingAddress", //Not currently supported but it illustrates the mechanism
        "options" : {
            "modal" : true,
            "closeTimeout" : 15000 
            //The dialogue stays open in a "waiting state" for 
            // 15 seconds after the user selects their credential
        }
    }).then(
            function(credential) {
                if (!credential)
                //We'll have to get the address through the website UI
                // so close the dialogue that's currently waiting for us to 
                // submit another request
                navigator.credentials.close();

                //Build request based on supplied address
                // i.e. with appropriate shipping options
                var paymentRequest = [
                        {
                            "methods": [
                                'https://w3id.org/payment-methods/traditional-card/#Visa',
                                'https://w3id.org/payment-methods/traditional-card/#Mastercard',
                                'https://w3id.org/payment-methods/traditional-card/#Discover'
                            ],
                            "details": {
                                "groups": [
                                    {
                                        "id": "shipping",
                                        "label": "Shipping",
                                        "default":  "shipping-standard"
                                    }
                                ],
                                "items": [
                                    {
                                        "id": "shipping-standard",
                                        "optionGroup": "shipping",
                                        "label": "Standard Shipping",
                                        "amount": {"currencyCode": "USD", "value": 0} // US$0.00
                                    },
                                    {
                                        "id": "shipping-express",
                                        "optionGroup": "shipping",
                                        "label": "Express Shipping",
                                        "amount": {"currencyCode": "USD", "value": 500} // US$0.00
                                    },
                                    {
                                        "id": "basket",
                                        "label": "Sub-total",
                                        "amount": {"currencyCode": "USD", "value": 5500} // US$55.00
                                    },
                                    {
                                        "id": "tax",
                                        "label": "Sales Tax",
                                        "amount": {"currencyCode": "USD", "value": 500} // US$5.00
                                    },
                                    {
                                        "id": "total",
                                        "label": "Total due",
                                        "amount": {"currencyCode": "USD", "value": 6000} // US$60.00
                                    }
                                ]
                            },
                            "data": {
                                "merchantNumber": 8762387623,
                                "encryption": {  //The payment method defines a mechanism for encrypting responses
                                    encryptResponseData: true,
                                    algorithm: "AES-CBC",
                                    publicKey: 'https://payment-service-provider.example.com/keys/12'
                                },
                                "signature": {  //The payment method defines a mechanism for signing the request...
                                    type: 'LinkedDataSignature2015',
                                    creator: 'https://payment-service-provider.example.com/keys/12',
                                    created: '2015-09-23T20:23:15Z',
                                    nonce: '239807882930744352',
                                    signatureValue: 'm4NTIyZTOGQzNGVkMzVkZ...OWM32NjIgoYzI43Q3ODIy='
                                },
                                "https://w3id.org/payment-methods/traditional-card/#Discover" : { //Method specific data
                                    "discover-merchant-identifier" : "44ba1fd7-74f7-4d47-b04a-7f01199bdaa5"
                                }
                            }
                        },
                        {
                            "methods": ['https://bitcoin.org'],
                            "details": {
                                "groups": [
                                    {
                                        "id": "shipping",
                                        "label": "Shipping",
                                        "default":  "shipping-standard"
                                    }
                                ],
                                "items": [
                                    {
                                        "id": "shipping-standard",
                                        "optionGroup": "shipping",
                                        "label": "Standard Shipping",
                                        "amount": {"currencyCode": "BTC", "value": 0} // BTC0.00
                                    },
                                    {
                                        "id": "shipping-express",
                                        "optionGroup": "shipping",
                                        "label": "Express Shipping",
                                        "amount": {"currencyCode": "BTC", "value": 24500} // BTC0.00245
                                    },
                                    {
                                        "id": "total",
                                        "label": "Total due",
                                        "amount": { "currencyCode": "BTC", "value": 12300000 } // BTC0.123
                                    }
                                ]
                            },
                            "data": {
                                "destination" : '3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC'
                            }
                        }
                    ];

                //Request payment
                navigator.payments.requestPayment(
                        req,
                        {
                            closeTimeout : 20000 //Wait 20 seconds for us to process the response
                        }
                ).then(function(paymentResponse){

                    //Process the payment
                    var result = processPaymentResponse(paymentResponse)

                    //Close the dialogue
                    navigator.payments.completePayment(result);

                }).catch(function(err) {
                    console.error("Uh oh, something bad happened", err.message);
                });
            });


    function processPaymentResponse(paymentResponse) {
        // Process paymentResponse
        return true;
    }

Some explanation of this request object example is here: https://github.com/WICG/paymentrequest/issues/41

[dlongley]

@zkoch,

I tried to address that in the sentence following the one you quoted. Much of abandonment, at least on mobile, happens long before the user arrives at the point of collecting payment information (coming from our research). So to improve only the final step doesn't go far enough.

In this research, shopping cart abandonment occurred 22% of the time because shipping costs were displayed too late in the payment process. This, it seems, could only be mitigated by requesting the shipping information (or a shipping estimate at the very least) earlier in the process. The current API would encourage merchants to collect shipping information and display updated final prices at the very end of the process, potentially codifying this portion of the shopping cart abandonment problem into the Web Payments API.

The research also indicates that 44% of shopping cart abandonment was due to the cost of shipping. It seems clear to me that the change of price at the last minute, after a user has already done all of their shopping is a very significant trigger for cart abandonment. This can be due to taxes or shipping or other costs that are hidden until too late in the process. Therefore, in my view, if we can, we should try to avoid building a high-level API that suggests that the merchant ought to collect shipping information late and adjust prices after a payment request has already been submitted.

In order to prevent abandonment, merchants need to be encouraged to include the cost of shipping in their products, offer free shipping, or collect shipping/location/taxes information earlier. We should be trying to push them in that direction, yet, I believe the current approach would encourage them to head the opposite way.

[burdges]

A priori, there is no reason a payment system needs to know anything about shipping. Also, there is an improvement in user privacy in shipping information is not communicated to the merchant unless the user deems it necessary and not sent earlier than necessary.

There is nothing that prevents a web shop from achieving the best of both worlds by offering a cart and shipping bar where users saw information like the value in their cart and shipping if know. And users could enter a fragment of the shipping information needed to compute shipping costs. I doubt payment needs to impact that flow however.

[msporny]

PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls because there may be work starting shortly in the Verifiable Claims work and the Credential Management API that would almost immediately deprecate the mechanism. The Web Payments Browser API may support it via a key/value pair in the payment request data or options object passed to the API if the Verifiable Claims / Credential Management APi fails.

[adrianhopebailie]

Moved @msporny proposal to it's own issue so that the discussion may continue on this thread if the proposal is not accepted.

[adrianhopebailie]

I think it's premature to try and resolve this question without seeing how the API would be implemented and used through some demos or wireframes. This issue is highly influenced by UX.

@msporny makes an argument against gathering the shipping address through the API on the basis that this should be done through more appropriate APIs.

The counter-argument is that browsers already hold this data today and should use it to make the checkout experience better for physical goods purchases AND the payments work should not create a dependency on work that hasn't even been chartered yet.

The flow is as follows:

1. Request shipping address (website)
2. Get shipping address from user (browser)
3. Calculate shipping costs (website)
4. Request payment (website)
5. Get payment app selection from user (browser)
6. Process payment request (payment app)

There is a UX-related argument that context switching the user between an address selection dialogue, the website and then a payment app selection dialogue is too much friction. i.e. Completely separate APIs and UI for steps 1 - 3 and then steps 4 - 6 as proposed will be a bad UX.

So there is a requirement to either:

1. have an API call for step 1 and another at step 4 but to reuse the same dialogue which never loses focus (thus making the UX seamless) but goes into a waiting state during step 3.
2. make a single API call at step 1 that instructs the browser to prompt the user for a shipping address as part of the flow

The advantage of 1 is that we have a separation of concerns between getting the shipping address and the payment request. This may negate the need to manage state of the payment request. The disadvantage is that if the website gets the shipping address and then never calls the payment request API you could have a dialogue in focus waiting for the website (and not taking input from the user). So to support this model you'd need to give the website an ability to close that dialogue explicitly or indicate that it will not be requesting a payment afterwards.

The advantage of option 2 is that the browser worries about when to show/hide the dialogue but this introduces a need for the website to be able to update the payment request mid-flow, in effect creating a similar flow to option 1. This seems like a poor design; if there is a high likelihood that the website will update the payment request after initially creating it then why force it to be created at step 1 at all?

COUNTER-PROPOSAL:

The API should allow the website to leverage the ability of the browser to efficiently gather a shipping address by exposing a function to do so. In time this will be deprecated in favor of more generic APIs like those being worked on by the VCTF. This API endpoint should be separate from the payment request API endpoint.

The API should also support the use case where the website does not intend to submit a payment request once it has the shipping address, or this process times out.

Example:

interface ShippingAddressResponse {
    Promise<void>                 closeDialogue();
    ...
}

[NoInterfaceObject]
interface Payments {
    Promise<PaymentResponse> requestPayment(...);
    Promise<ShippingAddressResponse> getShippingAddress(optional boolean closeDialogueAfter);
};

partial interface Navigator {
    readonly attribute Payments payments;
};

[msporny]

the payments work should not create a dependency on work that hasn't even been chartered yet.

This is false. The Credential Management API exists in an officially Chartered WG and is on the W3C Recommendation track:

https://www.w3.org/TR/credential-management/

[msporny]

In time this will be deprecated in favor of more generic APIs like those being worked on by the VCTF.

Do not build cruft into the Web Platform. The API call will /never/ be deprecated or removed from the browser because websites will start to depend on it. If we are going to do this, we must make a best effort to get it right. APIs for the Web Platform aren't like a software libraries - you can't deprecate them (unless next to no one uses them).

-1 to the counter-proposal that builds cruft into the Web Platform.

[ianbjacobs]

@msporny

On this thread you wrote "...because there may be work starting shortly in the Verifiable Claims work and the Credential Management API that would almost immediately deprecate the mechanism.." My comments about dependencies referred to the VCTF. I had not made the connection to the Credential Management API so need to think more about the relationship of that work to the current question of shipping data.

[adrianhopebailie]

This question was tabled as a proposal (#63) at the WG call on 21 Jan but not resolved.
Some of the discussion can be found in the minutes of that call.
The following discussion is copied from the proposal thread which is now closed as we endeavor to keep the discussion in one place.

@ianbjacobs wrote:

If we consider the WPWG's time frame, we had our first charter draft in June and launched the WG four months later. A conservative estimate of when an attributes WG might be launched is six months from now. Then it would require another 18 months minimum to get a Recommendation.

While I would like to see the attributes task force identify a problem where there is community consensus that W3C can add value through standards, I am concerned about a dependency of this work on that early work.

@msporny wrote:

We do not have to create a dependency. We just need to not include gathering shipping address information. Full stop.

The downside here is that merchants will have to gather shipping address information in the way they do today (solved problem, albeit not in the best way possible). The upside is that we don't build something into the Web platform that will almost certainly be cruft if the Verifiable Claims work is a success.

Also note that this work of getting a credential is already being done in the Web Applications Security Working Group via the Recommendation-track Credential Management API.

Mike West from Google is working on it, and it's confusing to me why someone else from Google (other than it's a large company and there is no communication happening between these two spec editors) is proposing something specific and separate from that API that does effectively the same thing.

@zkoch wrote:

I have confirmed with Mike West that this is not currently what is being proposed. They have built what is, in effect, a "sign in" API.

@mikewest wrote:

There is certainly "getting a credential" work being done in WebAppSec. It isn't clear to me that "shipping information" is such a credential. It's certainly not part of the proposal at https://w3c.github.io/webappsec-credential-management/.

@msporny wrote:

Hey @mikewest,

We've had a very lengthy set of conversations with you in WebAppSec over the past year about "more than just login credentials" use cases:

w3c/webappsec-credential-management#8
w3c/webappsec-credential-management#7
w3c/webappsec-credential-management#4

As a result of those conversations, there were changes made to the CM API spec, namely the Extension Points portion of the spec:

https://w3c.github.io/webappsec-credential-management/#implementation-extension

It's documented in the CM API that these sorts of credentials are of interest and Credentials CG, Web Payments IG, and Verifiable Claims Task Force are exploring the space and expect to use the Credentials Management API to implement these features:

https://w3c.github.io/webappsec-credential-management/#future-work

We (Digital Bazaar) even went to the trouble to align the Credential CG API w/ the Credential Management API because we thought there was agreement that the CM API could do this in the future. I realize that you're not currently chartered to do more than just login credentials. That's not the point.

The point is that there exists an API at W3C that is Recommendation track that /could/ gather shipping address information, and the Credentials CG and VCTF work intends to extend that API to do just that. However, the requestPayment API proposal intends to create its own API to gather shipping address information instead of extending the CM API (which could be done).

The question is, why isn't the requestPayment API not just extending the CM API? Why is it effectively re-inventing a very specific subset of the CM API?

@msporny wrote:

@zkoch wrote:

I have confirmed with Mike West that this is not currently what is being proposed. They have built what is, in effect, a "sign in" API.

There was a very active discussion a number of months ago where we asked that the CM API be renamed to something like "Login API" (because it wasn't doing generic 'Credentials'). There was push-back on that because there was an assertion that the CM API could be extended beyond just Login credentials (even though that's what they're currently chartered to do). The CM API has extension points to get other types of credentials that we have vetted over the past year to ensure that you could do things like getting shipping address credentials:

https://w3c.github.io/webappsec-credential-management/#implementation-extension

My point here is: there exists an API that we could do shipping address credentials through other than the paymentRequest API. So, why are we re-inventing the wheel in WPWG instead of re-using the CM API?

If @mikewest is asserting that the CM API is just for login credentials, then we should request that that API be renamed to something like the "Login Credential API" or the "Login Management API".

If @mikewest is asserting that the CM API does have extension points and it's up to other groups to use those as they see fit, then we should request that the paymentRequest API extend the CM API instead of re-inventing the wheel.

@mikewest wrote:

Hi, @msporny. I do indeed remember our conversations. :)

The credential types actually defined in the WebAppSec document do, in fact, boil down to "sign-in" stuff. https://w3c.github.io/webappsec-credential-management/ defines those types in terms of a number of extension points that folks like yourself can use in a number of ways to implement a number of things. The FIDO submission, for instance, is starting to explore areas beyond the boundaries of the spec we're working on in WebAppSec, and I do expect to see more of those kinds of concrete proposals in the future.

My point here is simply that WebAppSec's work in this area is fairly narrowly scoped by our charter to "assist[ing] users in managing the complexities of secure passwords" (which might not be "the" point, but is certainly "a" point). If this group agrees that the best way to make shipping addresses available is via the navigator.credentials API, I'd suggest putting together a concrete proposal, and pitching it to developers and implementers. I'd certainly be interested in reading through it.

@dlongley wrote:

For reference, here's some of the code that the Credentials CG has been working on that was refactored to extend the Credential Management API: https://github.com/digitalbazaar/credentials-polyfill

@bifurcation wrote:

The FIDO submission, for instance, is starting to explore areas beyond the boundaries of the spec we're working on in WebAppSec, and I do expect to see more of those kinds of concrete proposals in the future.

Nonetheless, these proposals are still dealing with authentication, so they're still very distinct from what the CG has been talking about.

If this group agrees that the best way to make shipping addresses available is via the navigator.credentials API, I'd suggest putting together a concrete proposal, and pitching it to developers and implementers. I'd certainly be interested in reading through it.

As would I. But to be clear, I would very strongly oppose the addition of such work to the WebAppSec charter.

@dlongley wrote:

@bifurcation,

Nonetheless, these proposals are still dealing with authentication, so they're still very distinct from what the CG has been talking about.

I agree that the CG is doing something different from the Web Authentication group. The CG work is about verifiable claims/attributes. This is a layer above the FIDO/Web Authentication work because it has to do with what is out of scope for that group (e.g. multi-origin credentials/federated identity/etc.), but that doesn't mean it has no relation to authentication, e.g. did entity A really make claim B about entity C?

The two groups are doing different things at different layers, but both see the Credential Management API as a potential fit (and the CG has built a demo that shows that fit).

As would I. But to be clear, I would very strongly oppose the addition of such work to the WebAppSec charter.

I think we should wait off and let the CG/VCTF do their work which will hopefully result in an appropriately chartered WG that would work on any extension that is relevant to that work.

@nickjshearer wrote:

To be honest, I am very confused by the notion being put forward that a shipping address is a "credential" in the first place. In the Credential CG group's own glossary a credential is defined as:

A set of claims that refer to a qualification, achievement, personal quality, aspect of an identity such as a name, government ID, preferred payment processor, home address, or university degree typically used to indicate suitability.

A shipping address is none of these things. It may be a home address, but it equally may be an address a friend gave me and I have no proof that it is or isn't real.

Surely nobody would propose a latitude/longitude coordinate be a "credential"? So why is a shipping address any different? Like a pair of coordinates it represents a physical location. Calling it a credential seems like some serious overreaching.

@msporny wrote:

A shipping address is none of these things. It may be a home address, but it equally may be an address a friend gave me and I have no proof that it is or isn't real.

The United States Post Office, UPS, and FedEx are interested in issuing digitally signed shipping address credentials to people and organizations. Doing so, and enabling people to use those instead of something they type into an online form would reduce tens of millions of dollars in wasted effort re-routing misrouted packages.

Note that the definition of "credential" in the Credential CG's glossary uses 'such as' before the examples. A credential can be any set of claims about an entity. Saying that "Person X can receive packages at Address Y" makes Address Y a credential of Person X (at least, that's how the Credential CG has decided to model things - and it works pretty well across a variety of market verticals).

Surely nobody would propose a latitude/longitude coordinate be a "credential"?

They would. For example, a lat/long credential issued to a person via a mobile phone provider with a timeout of 3 hours would enable that person to consume region-locked content on a particular website without tight coupling between the mobile phone provider network and the content provider.

Calling it a credential seems like some serious overreaching.

It fits the dictionary definition of a credential, so I don't quite see why you think it's overreaching.

Do you mean that calling a shipping address credential a credential as it is defined in the Credential Management API is overreaching? If so, I agree, but that's only because the Credential Management API has a very narrow definition of credential at the moment (what they really mean are 'a small subset of credentials that can only be used to login'). That said, we've had the discussion w/ @mikewest about extensibility in the CM API and the answer we got back wasn't "the CM API isn't extensible enough to support the types of credentials that the Credential CG is working on".

@nickjshearer wrote:

It fits the dictionary definition of a credential, so I don't quite see why you think it's overreaching.

Because that definition of 'credential' is so vague as to encompass everything. If you say a credential is a "set of claims about an entity" then it follows that any property of an object is inherently a credential. For example, take a Java interface. An object can claim to implement an interface, which would by your definition make the interface a credential of the object. It's credentials all the way down.

This proposal seems to be built around the assumption that a shipping address is always a credential, but I don't think that assumption has been proven. Because of that, the proposal seems premature.

David Singer [email protected] wrote:

A credential can be any set of claims about an entity.

Surely a set of claims about an entity are simply properties? A credential would be a claim or property that both needs to be, and can be, verified.

[msporny]

Surely a set of claims about an entity are simply properties? A credential would be a claim or property that both needs to be, and can be, verified.

Self-issued credentials may or may not be able to be verified. We're splitting hairs at this point, but the Credentials CG has a pretty solid model about how we think about these sorts of things, and it goes something like this:

• Entities have properties associated with them (no surprise here).
• Entities can make statements (aka claims/attestations) about properties related to themselves or other entities - we call this data structure a credential.
• A credential may or may not be able to be verified (it may or may not have a digital signature).
• Low-stakes credentials are typically unsigned ("I took a rock climbing class last week").
• High-stakes credentials are typically signed ("I'm a board certified doctor in Florida").

A shipping address can be low-stakes (ship this box of gum to this address), or it can be high-stakes (ship this box of guns to this address). Clearly the latter use case could benefit from a verifiable address credential (along with a whole slew of other verifiable credentials).

This whole proposal seems to be built around the assumption that a shipping address is always a credential, but I don't think that assumption has been proven.

The proposal is built around the assumption that there are other groups working on this problem in a generalized way and the PaymentRequest approach for gathering a shipping address seems to 1) overlap heavily with that work, and/or 2) be a highly specific solution to a more general problem (collection of payment related information - what about billing address, what about loyalty card, what about coupons and discount codes - why aren't we special casing those things as well?).

What do we lose from not putting this "shipping address collection" feature in Phase I (other than some downside from a usability perspective)?

[dlongley]

I've offered a proposal that includes shipping address collection here:

https://github.com/w3c/webpayments/wiki/Checkout-API

[msporny]

Closing this issue as the browser vendors seem to be determined to put shipping address collection in the payments API and multiple attempts at properly layering the APIs have failed.