Manu Sporny: Last week we covered general comments, not a lot of response to it, so we may be good as far as that's concerned ✪

Manu Sporny: We need to add the credential CG launch to the agenda, we're going to try to do that today, get all the paperwork for that worked out and get that launched today ✪

Manu Sporny: Any changes to the agenda? ✪

David I. Lehn: None ✪

Manu Sporny: The charter for the group is here: https://docs.google.com/document/d/1dPzWbPF0jlox8UHnr522nBWCjLJMQ_vGbbtsA5-pAsg/edit ✪

Manu Sporny: We have had feedback from orgs that aren't part of web payments but are part of the education community, the charter has been approved by other orgs that plan on joining, the order of operations will be to create the CG today after making some last few modifications to the charter, we'll send out a call for participation, then we're going to be asking for launch partners through the rest of the month, we're going to gather all the large companies that want to be part of the announcement of the group to the press; the group is for the standardization of credentials for use in payments, education/learning, and background checks. ✪

Manu Sporny: Aug 7th-9th: W3C Credentials CG is created at W3C (paperwork complete) ✪

Manu Sporny: Aug 10th-30th: Revise charter, determine telecon times, have at least 1 call, gather "launch partners" for formal public announcement at the end of August, vote on charter ✪

Manu Sporny: Aug 19th: Presentation of Credentials CG initiative at SemTech 2014, ask of audience is: join the work, meet at Credentials CG ✪

Manu Sporny: https://web-payments.org/slides/2014/semtech/ ✪

Manu Sporny: http://semtechbizsj2014.semanticweb.com/sessionPop.cfm?confid=82&proposalid=6674 ✪

Manu Sporny: Sep 2-5th: United Nations - Internet Governance Forum - The Payment, Privacy, Policing Paradox Workshop ✪

Manu Sporny: http://igf2014.sched.org/event/781846f97d253b11129ee88f4dd176ff ✪

Manu Sporny: Gather regulatory, policy, and legal concerns, recruit the necessary governments and law makers to provide input on the privacy / law issues ✪

Manu Sporny: Sept 15-Oct 25th: Weekly Credentials CG telecons, picking WG chairs, discuss use cases and requirements, determine when technical specs will be ready to go standards-track at W3C ✪

Manu Sporny: Oct 27th-31st: W3C Technical Plenary - 1st Web Payments Face-to-Face (credentials are an element), 1st Credentials CG Face-to-Face (unconference session) ✪

Manu Sporny: http://www.w3.org/2014/11/TPAC/ ✪

Manu Sporny: Any questions on the credentials schedule? ✪

Manu Sporny: Identity use cases: https://www.w3.org/community/webpayments/wiki/UseCases#Identity ✪

Manu Sporny: So, we're starting with this use case: Store basic credentials and payment provider information on the Web in a way that is easy to share with various payees/merchants given authorization by the owner (payee) of the credential, and that is easy to synchronize between devices. ✪

Manu Sporny: Input from Steven Rowat: I think we need to have more discussion about identity's implications before deciding whether to attempt to do it together with web payments. ✪

Manu Sporny: Input from Adrian: Not required for first iteration. It is not ESSENTIAL for the payer to exchange identity credentials to complete a basic transaction. Think this should be the focus of 2nd iteration. ✪

Manu Sporny: With the credential CG happening, i think what we're doing is offloading all of this identity discussion to that CG, if there's concern in the web payments CG for identity derailing us, the credential CG will pick up the use cases ✪

Dave Longley: I think what's most important in the web payments work is that there is some way to link to an identity via a URL. We should consider whether the Credential CG, having that link should be enough for what we want to do w/ Web Payments. If all we need to do in Web Payments is ensure that the URL is available, then all the details can be worked out by the Credentials CG. [scribe assist by Manu Sporny] ✪

Dave Longley: The goal is to decouple as much as possible, but still cover all the use cases we wanted to. We can consider this a first iteration where we want to concern ourselves with those pieces. [scribe assist by Manu Sporny] ✪

Manu Sporny: If we take this path and if for whatever reason the credentials CG fails, we could use OpenID connect to establish the URL, but we wouldn't get anonymity, privacy, etc. and of those things ✪

Manu Sporny: But at least we could do something ✪

Manu Sporny: So i think that addresses steven and adrian's comments, re: steven, it's the other group's decision to figure things out, and re: adrian, we aren't handling the identity stuff for iteration one ✪

Manu Sporny: Ok, on to the next use case - Use Case: Steve (buyer) visits a website (merchant) and authorizes the transmission of one or more credentials (such as proof-of-age, shipping address, etc.) previously stored with a credential storage service to the website to enable access or fulfillment of a transaction. ✪

Manu Sporny: Feedback from Adrian: Not required for first iteration. It is not ESSENTIAL for the payer to exchange identity credentials to complete a basic transaction. Think this should be the focus of 2nd iteration. ✪

Manu Sporny: So, resolution for both is: A Credentials CG is being created to handle all identity requirements for Web Payments (and other market verticals). The Web Payments CG will proceed assuming that there will be a mechanism to establish an identity URL for participants in a transaction. ✪

Manu Sporny: Next use case is: Using metadata that is the result of a transaction, discover attributes associated with the participants (payer, payee, buyer, merchant) in the transaction. ✪

Manu Sporny: Response from Steven Rowat: wouldn't someone in the NSA be doing exactly this? Or Google, to get data to drive advertising revenue? Isn't there a good case that this is unconstitutional in the US? I don't think this is what you mean...but what do you mean? Who needs to discover attributes associated with the identity of the participants? Why not just ask the participants? ✪

Manu Sporny: Steven's questions all surround who has the rights to the data ✪

Manu Sporny: His concerns would be that someone could get meta data from the receipt, but that's not what we want it's up to the owner of the identity to release the data ✪

Dave Longley: There was a lot of misunderstanding over this use case. This isn't meant to wipe out all other use cases about privacy. This was about the participants being able to access other participants data WITH THE STRICT APPROVAL of the requestee. [scribe assist by Manu Sporny] ✪

Dave Longley: If you want to provide the information, there is a mechanism to do so. We should reword it. "Should the participants agree..." [scribe assist by Manu Sporny] ✪

Dave Longley: I think that resolves all of Steven's questions. [scribe assist by Manu Sporny] ✪

Dave Longley: What about: Given permission from participants in a transaction, metadata can be obtained to discover attributes associated with those participants (payer, payee, buyer, merchant). ✪

Dave Longley: We may want to talk about real-time authorization and interactive authorization. Preauthorization via some sort of digital signature, or interactive authorization. [scribe assist by Manu Sporny] ✪

Manu Sporny: Given permission from participants (payer, payee, buyer, merchant) in a transaction, use transaction metadata to discover additional attributes (name, address, preferred financial account) associated with the participants in the transaction in real-time or via an interactive mechanism. ✪

Manu Sporny: The gist of the use case is that "you have just completed a transaction with these people and you may want to find out more information about them post-transaction" ✪

Dave Longley: Given the permission of the participants of a transaction, its metadata can be used to discover additional attributes associated with those participants. ✪

Evgeny Vinogradov: After a transaction has been completed you can't be sure that the information you obtained will be exactly the same afterwards as it was at the time of the txn ✪

Manu Sporny: That's true. It's a problem wrt. fraud, but it may also be a benefit (getting the most recent, up to date email address or shipping address for a customer). ✪

Dave Longley: This sounds like you need data in the receipt and have that information only accessible to people involved in the transaction. [scribe assist by Manu Sporny] ✪

Dave Longley: This is private information that's a part of the receipt. [scribe assist by Manu Sporny] ✪

Dave Longley: We are talking about having metadata in the receipt itself, in the transaction metadata somewhere. [scribe assist by Manu Sporny] ✪

Dave Longley: We need to make sure that these receipts are private pieces of information, only accessible by private participants in the transaction. Some of the information is only available to some of the participants in the transaction. [scribe assist by Manu Sporny] ✪

Dave Longley: This use case is really about two things - you can store metadata that is directly related to the transaction in the digital receipt, and you can indicate who is allowed (of the participants in the transaction), who can see what pieces of information. [scribe assist by Manu Sporny] ✪

Dave Longley: I think the original design was to leave as much as possible out of digital receipt as possible. [scribe assist by Manu Sporny] ✪

Dave Longley: In one case, the information is in the digital receipt, in other cases, it's not. [scribe assist by Manu Sporny] ✪

Manu Sporny: It's the latter, there are pointers, the information lives elsewhere. [scribe assist by Manu Sporny] ✪

Manu Sporny: Given the permission of the participants (payer, payee, buyer, merchant) of a transaction, the transaction metadata can be used to discover additional attributes associated with those participants. For example, given the buyer's authorization, a merchant could query the identity URL for the buyer contained in a digital receipt and obtain an up-to-date shipping address. ✪

Dave Longley: Another example could be a merchant querying the identity for an up-to-date email address. Keep in mind that this can always be done before the fact, as a part of the login process to the website. The login process would ask for an email credential, shipping address credential, etc. [scribe assist by Manu Sporny] ✪

Evgeny Vinogradov: Allowing a change to the shipping address after the transaction was made could affect fraud or sales tax, etc ✪

Dave Longley: Yes, this is an issue. We should make this clear - obtaining information after the fact might have regulatory and fraud implications. [scribe assist by Manu Sporny] ✪

Dave Longley: The next use case: "Use Case: Digitally verifiable credentials such that a merchant and payment processor involved in a transaction can prove that they have performed the proper due diligence when identifying the payer and the payee (KYC)." ✪

Dave Longley: This, again, falls under the previous resolution ✪

Dave Longley: For pushing this off to the credentials CG ✪

Manu Sporny: Once we go over these use cases we'll send them over to the credentials CG ✪

Manu Sporny: So, this one is next - Use Case: Use an existing, widely deployed identity provider mechanism (i.e. OpenID Connect) to integrate with the digital credentials sharing and payments initiation process. ✪

Manu Sporny: Input from Steven Rowat: would the 'existing, widely deployed' mechanism be part of the specification and go through the same W3C process, and end up being a supported (necessary? sufficient?) part of the whole mechanism? Or is it implied that the i.d. provider mechanism would remain outside the W3C process, which would nonetheless be designed as a socket for it? Or would the payment mechanism have a socket that could fit any number of identity provider mechanisms, without prejudice, but this one is being specified so that there will at least be one example that works for sure? If so, are there downsides to this? For instance, are there other provider or potential provider mechanisms whose developers will be annoyed by being passed over? Or, are there yet-to-be imagined mechanisms that might be better than the chosen existing one, potential mechanisms which will now fail to be developed because one has been already blessed by (association with) the W3C? ✪

Manu Sporny: Re: part of w3c, openID connect has already gone through some other standardization process, so no need to discuss that, if we go with identity credentials, that will have to be a part of the Credentials CG work. ✪

Manu Sporny: Re: would IDP be outside w3c? if it's identity credentials it's inside w3c, if it's openID connect it's outside ✪

Manu Sporny: Re: specifying the tech ... yes, we have to specify the tech in a way that IDP mechanisms can be pluggable, if they fail, we need a way to have a mechanism establish a URL so that the rest of the stuff can stick together. The payment stuff depends on there being a URL. ✪

Manu Sporny: Whether it's openID connect, IC stuff, or something else, it's up in the air ✪

Manu Sporny: Re: downsides? yes, depending on which way we go ✪

Manu Sporny: If IC is selected, openID connect people could be fairly pissed off about it, if openID connect is selected then IC will be annoyed as it doesn't have third-party digital signatures, JSON-LD, etc. ✪

Manu Sporny: We are saying that IC spec is going to support openID connect in some way ✪

Manu Sporny: So we get best of both ✪

Manu Sporny: Re: can we imagine something better ... we don't know how successful any of this will be, it's an open question, if both fail there will be a better mechanism eventually, we want to make the payments stuff fairly agnostic for how you establish and query the identity URL ✪

Manu Sporny: That said, i don't think that there are any changes to the use case ✪

Manu Sporny: These are just clarifying questions ✪

Dave Longley: We could try to decouple and abstract identity away as much as possible. So, one could use whatever solution that wins in the identity space. [scribe assist by Manu Sporny] ✪

Manu Sporny: Ok, so, Decouple and abstract identity away as much as possible. So, one could use whatever solution that wins in the identity space. No change required for the use case, clarifications have been made on the mailing list and telecon. ✪

Manu Sporny: Next use case: Enable anonymous transactions such that the identity of the payee is not discoverable by payees, merchants, or payment processors. ✪

Manu Sporny: Input from Steven Rowat: Do you mean 'but can be discoverable by governments or law enforcement when they have appropriate authorization'? If so, +1, but I think it would be best to include that explicitly. ✪

Dave Longley: I don't see how that could be done, where payees, merchants, and payment processors can't know who you are... but governments can? [scribe assist by Manu Sporny] ✪

Manu Sporny: The government could assign an identity token where they can only tie it back to the citizen. [scribe assist by Manu Sporny] ✪

Dave Longley: I meant, I don't see how this could be feasibly done. [scribe assist by Manu Sporny] ✪

Evgeny Vinogradov: We have to keep in mind governments usually make the payment service providers responsible for ensuring that the identity can be linked back to a citizen, gov't doesn't do KYC clearing by themselves ✪

Manu Sporny: Yes, good point Evgeny. ✪

Dave Longley: If you want to use some sort of cryptocurrency that supports this, you should use that. This doesn't have to be a part of the standardization process. [scribe assist by Manu Sporny] ✪

Manu Sporny: The purpose is to have a cash equivalent ✪

Dave Longley: I don't think the technologies are worked out for truly anonymous transactions. For example, bitcoin is traceable, zerocash is better, but still being researched. [scribe assist by Manu Sporny] ✪

Manu Sporny: Ok, so position on this is: We do not believe that this is a version 1 feature because the technology to achieve it is still being actively researched and developed. ✪

Dave Longley: Bitcoin is far more anonymous than other mechanisms, but it doesn't fully achieve the fully anonymous goal. [scribe assist by Manu Sporny] ✪