Manu: We need good shared understanding of "Credentials"
... I want to be sure we have shared understanding of what we mean by credentials

<manu> A credential is a qualification, achievement, quality, or piece of information about an entity’s background such as a name, home address, government ID, professional license, or university degree, typically used to indicate suitability. The use of credentials to demonstrate capability, membership, status, and minimum legal requirements is a practice as old as society itself.

Erik: I have a similar understanding
... regulatory bodies would include additional information

Manu: I think "your dog's name" still fits into the above definition (e.g., your background)
... I have concerns about the rabbit hole of "solving identity for the web"

Erik: Our scope is to address account provider needs

Manu/Erik: Credentials are part of establishing identity

<manu> Credentials Executive Summary: https://docs.google.com/document/d/1Nq543-Am1hQUIZ2hhzAFl8KexvIEBwDDc_f3Ikz1opQ/edit

<Zakim> dsr, you wanted to note relationship to intent based API for KYC

dsr: This relates to our interest in KYC and generic mechanisms for doing so
... various approaches to "how you name things"
... in some cases people may want to use existing credentials.
... so there are three things:

- using existing credentials (as currently expressed digitally)

- a generic framework for expressing credentials

- an API that provides access to the binding between a web identity and a real-world identity

<dsr> see blog post http://www.w3.org/blog/wpig/page/3/

Manu: Many existing credentials exist in non-web-like fashion (e.g,. in PDF). we investigated reusing existing credentials and it was challenging.

<Erik> I agree with Manu. Credentials has no standard yet.

<Erik> Credentials should be a W3C initiated focus

IJ: I want to focus on (1) what our use cases are (2) what the landscape is for credential approaches (and what has succeeded or not with them) and (3) background on the CG's work

DSR: PrimeLife project on privacy
... Privacy requirements are part of this discussion / use case

<Zakim> dsr, you wanted to note privacy requirements as part of the discussion on credentials

Manu: Yes. The group deeply cares about privacy (which comes up frequently both because it's important and also because of regulatory needs)

Erik: Credentials are good input to identity solution

<dezell> 1) Validate for purpose of payment.

<dezell> 2) Reuse for other purposes.

<dezell> 3) Common construction with other purposes.

<dezell> [so what is the "must have" profile for payments. Will only the ultimate credential do?]

Q. Where do credentials appear in the payments flow?

IJ: E.g., just at account creation? Or at other times/

Manu: Here's a full flow:

- you are signing up for a bank account or a stored value account.

scribe: that organization would really like to receive a credential (that has been digitally signed) that does the binding between real-world identity and web identity
... they can do the KYC clearing almost immediately upon receiving the information.
... so that's the ACCOUNT CREATION use case

- some additional ideas:

a) If you go to a web site and the site needs to know who processes payments for you (e.g., firstdata, google wallet, etc.).

scribe: once the site gets the credential they know that you have an account.
... you don't need to tell the merchant WHO YOU ARE, they just need to know that you have an account for when you receive an invoice

b) Coupons and loyalty cards can be viewed as credentials as well

c) Shipping addresses can be seen as credentials

scribe: this is more convenient (browser just ships credentialed address to the site; no form is necessary)
... but the other use cases have to do with controlled substances
... e.g, you can only ship them to verified addresses....or if you want to buy other things like fireworks or ammo or other things that required verified shipping addresses
... another use case would be geofencing

d) Proof of age is another use case during purchase flow (e.g., for purchasing wine)

IJ: I am hearing:

* Account creation

* At time of purchase

scribe: agreement to terms specifically

* At time of choice of instrument

DSR: I remember Erik talking about AML reqs

Erik: Security and credentials help you with KYC, AML, consumer protection

Q. How much / what would we need to standardize?

Manu: I think we need:

* Container for credential

(and we are proposing linked data with a digital signature)

* Protocol for issuing, storing credential

* Protocol for requesting a credential

Erik: +1 to standardizing the credential container

<manu> Ian: One way to structure the discussion...

<manu> Ian: What is the business opportunity - will it justify the need for standards work to be done?

<manu> Ian: It's rooted in the current state of KYC/AML - understand the limitations and cost today. Setting up a banking account is very expensive for the bank.

<manu> Ian: How are the regulatory requirements addressed today? They are handled, but it's time consuming and expensive - furthermore, only a small sliver of the world is engaging in this.

<manu> Ian: Tech companies, card processors - they're not standing to lose by having an improved system. They would be interested in systems that would make this work easier - safer for consumers. Frame it as that being the reason for why there is value for being a standard.

<manu> Ian: Coming to the meeting and saying: "This is the industry problem we want to solve, and here are some stories"

<manu> Ian: What has been tried before? Why did it fail? Successes and failures of industry-wide standards - some more weblike than others.

<manu> Ian: Before we go about CG work - inherent limitations to these things? why did adoption fail?

<Zakim> dsr, you wanted to comment on role of protocols

<dsr> +1 to documenting rationale

dsr: Manu mentioned protocols
... we need to understand the motivation and use cases for them.
... it's not clear to me that protocols come into the picture.

Erik: I would focus on how the credential is represented and stored.

Manu: I think we can't have interop unless we say how these credentials get around the Web.

DSR: What do you mean by protocols?

Manu: Other things to mention:

<manu> Ian: 3 big chunks that we've been talking about in first round of prioritization

<manu> Ian: Payment initiation, proofs, and invoices in v1

<manu> Ian: We have a draft - 20% of a charter on that work.

<manu> Ian: Need to have a shared understanding - worth the investment of time

<manu> Ian: Adrian's settlement task force - bridging disparate payment systems - in v1 - of the 3, that's the one we've discussed the least.

<manu> Ian: What needs to be proposed - authentication?

Manu: Authentication stuff is parallel to credentials work.
... should not have a dependency unless we were to bake hardware-based authentication in V1
... on the other hand, the digital signature work is vitally important
... and I am concerned we are going to have a conflict between JOSE work and digital signatures on credentials

[Discussion of need to have the right people embracing the effort]

Erik: Tech + financial

Manu: I will put together an outline
... and I would appreciate feedback on that so that we go into FTF with a unified message around credentials

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

No ScribeNick specified.  Guessing ScribeNick: Ian
Inferring Scribes: Ian

WARNING: No "Topic:" lines found.

Default Present: Erik, Ian, Dsr, dezell, manu
Present: Erik Ian Dsr dezell manu

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 26 May 2015
Guessing minutes URL: http://www.w3.org/2015/05/26-wpay-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report