The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

Credentials CG Telecon

Minutes for 2014-09-16

Mary Bold is scribing.
Meeting convened at top of hour by Manu Sporny.
Manu introduced the scribing process to the group. With this meeting, rotating scribes will follow the schedule in the announcement. Transcript errors can be corrected after the call.
Manu Sporny: We will wait until 5 after the hour and then get started.
Manu Sporny: Evgeny, are you going to be able to come to TPAC in the U.S.
Evgeny Vinogradov: Unsure.
Manu Sporny: Let's go ahead and get started. Our agenda is linked on screen. We need to discuss Mark Leuba's offer to liaison to higher ed standards groups.
Manu Sporny: Agenda items-- are there any other requests for the agenda?
David I. Lehn: None.

Topic: W3C TPAC Preparation

Manu Sporny: W3C TPAC preparation: the link to TPAC registration form is on screen.
Manu Sporny: We are hoping to have the Web Payments group approved, with expectation of approval but not known until mid-October. We are seeing a lot of support.
Manu Sporny: On the Monday and Tuesday of W3C TPAC, will be meetings of the Web Payments group. Monday & Tuesday, 11-3, hours for "ad hoc" meetings. Presumably, that's when CCG can meet.
Manu Sporny: In the Web Payments group, there will be break-out discussions for government, education.
Manu Sporny: If you are attending TPAC, definitely plan for Monday and Tuesday. If you can attend Wednesday, that's for larger meeetings and the Gala.
Manu Sporny: Between now and end Oct, we need to think about what topics need to be addressed, e.g., we think identity is not an optional thing on the web, education and government identity are a part of this, topic is broader than just financial identity.
Manu Sporny: Register via the link. Non-members can attend but must be "cleared" by W3C to attend. Let me know if you want to go and I'll connect with the people to get you into the meetings.
Manu Sporny: Stephane Boyera and Karen Myers are the contacts that we can communicate with to have you vetted as an invited expert.
Manu Sporny: Other q's on TPAC?

Topic: Mark as Liason to IMS Global and PESC

Manu Sporny: Mark Leuba has been on the call before but is not present today. He would like to be the liaison to IMS and PESC. Standards bodies for learning, education. IMS interest is identity. PESC, I don't have knowledge of. Mark has history with both organizations. We have talked with IMS and they are interested in the work.
Manu Sporny: Comments?
Chris Webber: I don't have a problem with Mark (lots of experience) but I am interested in talking with him. Can we have a special session to discuss how we are going to position this to the IMS?
Manu Sporny: You have Mark's email address. It would be good to pull in Bill Gebert from ETS and Mary or Eric from Accreditrust. There's no reason we cannot have more than one liaison, if you'd like a liaison from Badge Alliance of OBI.
Manu Sporny: Maybe we should set aside time in next call to discuss these matters.
Chris McAvoy: Yes.
Manu Sporny: We'll carve out time on the next call.
Tim Holborn: Seeking higher ed subject matter experts
Manu Sporny: We are heavy on the Western regions. Would help to have someone from Australia / Asia-Pacific, for example.
Tim Holborn: Sub-committee for education?
Manu Sporny: My concern is that we might duplicate work of Badge Alliance. Chris may have opinion. We'll trying to keep the work tightly on technical here.
Chris McAvoy: I agree. I don't want to say that we should talk about that stuff only in Badge Alliance groups.
Chris McAvoy: IMS is the 800lb. gorilla in the room in terms of education standards. They will be involved at some point.
Manu Sporny: Tim, you should definitely reach out to involve more people.
Tim Holborn: I need to reach out and identify someone for the education space. Work out some connections with universities. I am not ready to nominate someone at this point.
Tim Holborn: Badge Alliance, I am aware of.
Manu Sporny: If nothing else on this topic, we'll pick it up next week.

Topic: Charter Vote Result

Manu Sporny: Result of charter vote: 2-week open vote, results are visible on the linked page. Great turn-out from this small group, with unanimous approval. Anyone can object to the charter at any point and call for a vote to update or change the charter at any time.
Manu Sporny: Anyone can call for changes; having a current charter does not mean it is set in stone. I believe Tim already has a set of changes or additions. Proposed on the mailing list and then we will schedule discussion and another vote.
Tim Holborn: Shared google-doc? Or some other collaborative doc?
Manu Sporny: The doc you have, it's difficult for me to pick out the changes; there does not appear to be track-changing.
Manu Sporny: Might be easier for people to indicate "please change this..." and then re-send to the group?
Manu Sporny: I don't know if it should be a collaborative doc?
Tim Holborn: Taking it offline; will come up with something that will work. Thank you.
Manu Sporny: Thanks, Tim. Any comments about the charter vote? Other comments?

Topic: Web Payments Use Case Review

Manu Sporny: Last week, we began use case reviews and got about half-way through. (Link on screen.)
Manu Sporny: The last use case was pair
Manu Sporny: Last time we ended at this - Use Case: A payer executes a transaction without revealing secrets that are not vital to the transaction (e.g. identity, passwords, PINs or other information that the merchant does not need to know).
Manu Sporny: This is just a pass to go over the use cases and design criteria. We will return to discuss in detail.
Manu Sporny: At high level, are they manageable and useful?
Tim Holborn: I have made comments, have you been able to see them?
Manu Sporny: Yes, if we get through these today, we'll pick them up.
Manu Sporny: These use cases came from the Web Payments CG and have already been through 2 reviews since May.
Manu Sporny: Took a long time but they are better because of the review.
Manu Sporny: Design Criteria: Consider using existing, widely deployed identity provider mechanisms (e.g. Facebook Connect, OpenID Connect, G+ Sign-In, etc.) to integrate with the digital credentials sharing and payments initiation process. Only invent a new mechanism if the current identity provider mechanisms do not provide the functionality necessary to achieve the use cases promoted by the group.
Manu Sporny: A use case is something you want to be able to do. Design criteria are we want to be consider...
Manu Sporny: Design Criteria - if we really care about customer privacy, using OpenID Connect is problematic because tracking is visible.
Manu Sporny: Questions or concerns about what this Design Criteria means?
Manu Sporny: Identity credential we have now covers reading and writing.
Manu Sporny: There's only so much privacy possible bc of the digital signature on it.
Manu Sporny: We havent' come up with a set of best pracitices.
Tim Holborn: Is there a mechanism for providing a badge?
Manu Sporny: Badge and credential are interoperable in vocabulary.
Dave Longley: Badge is sub-set of a credential.
Manu Sporny: Data rights of these cases. We should have some mechanism to create data rights.
Tim Holborn: Like Creative Commons, identify one data rights mechanism from another. If not part of the decision-making process of how a person decides to use their credentials.
Manu Sporny: This design credential alludes to the possibility of another, which is a new way of logging in on the Web.
Manu Sporny: Log-in tokens: go to Web site and show govt-issued credential to get access rights to a Web site. That's an open question. The design criteria assumes that we could spawn a new log-in mechanism for the Web that would be privacy protecting.
Tim Holborn: We need to pay attention to data rights - the ability to describe when mechanism the person is using. Facebook Connect or OpenID -- is part of that specification -- how that credential is going to be used? Do you get what I'm coming from?
Manu Sporny: There are 3 separable things here: 1) data rights, 2) how credentials are used with legacy systems, and 3) is there a way to use credentials for log-in? 3 separate questions.
Tim Holborn: Web ID isn't in that list, it probably should be.
USE CASE: Transact with a merchant without revealing any identifying information. Identifying information is available to the payment processor.
Manu Sporny: Anything else about this particular design criteria before moving on?
Manu Sporny: Use case - interact with merchant - pseudo-anonymous transaction wrt. merchant, but known identity wrt. payment processor..
Tim Holborn: Does the transaction include receipt?
Manu Sporny: Yes, and that could lead to an accidental violation of privacy, for example if name in URL is visible.
Manu Sporny: Anonymous purchase - candy bar or magazine or under $10K purchase, benign, you should be able to communicate with the merchant in an anonymous way.
Tim Holborn: Separate use case for 5-cent?
Manu Sporny: Falls more into the Web Payments. Do you think there's a case of micro-payments that needs attention for credentials in this group?
Tim Holborn: Yes, how credentials might be commercialized. Transaction of 5-cents, such as a contribution to a Web site.
Tim Holborn: You would have to declare who you are. Are you able to give them that money?
Manu Sporny: You can be anonymous with merchant but the payment processor knows your identity.
Tim Holborn: When is it possible to do fully anonymous transactions?
Manu Sporny: Depends on the country.
Manu Sporny: Pseudo-anonymous transactions every day in convenience stores.
Pat Adler: Question - kinds of transactions that require credentials sent to the merchant? These are all aspects of the transaction. Some transactions require lots of identity information, others none.
Pat Adler: Identity belongs to the consumer; some instances the identity belongs to the corporation asserting the validity of that identity.
Manu Sporny: Technologies we have right now allow that to happen.
Manu Sporny: In other cases, you shouldn't have to give any of it over to the merchant if you don't want to. The choice is with the consumer (or the entity that holds the identity credentials, which is often the entity that the credential is about).
Dave Longley: The technology is built for minimum amount of information, then decide to give more.
Pat Adler: Are there ways of maintaining my identity ... not rely on those credential providers?
Manu Sporny: All of the technologies we're creating here are completely consumer-focused. The entity with final say is the person whose identity is being expressed.
Manu Sporny: Govt-issued passport; you keep that in your personal store; you decide how to share with a merchant or third party.
Manu Sporny: Assure this is like your wallet. You decide where to store it and who to give it to.
Tim Holborn: Links posted.
Manu Sporny: We're trying to create a lot of consumer choice. Today online, the corporation knows where you are logging into and then bundles that information and sells it.
Manu Sporny: Pat, does this make sense?
Pat Adler: Yes, I was hoping that was what your answer was going to be. Even in the corporate world, transport across organizations is problematic, a dynamic that might be down the road for this. Pluggable, transportable identity.
Tim Holborn: Everyone has the right to identity. ... accessible by Web applications from a storage location... at the core of it. Depending on how you want to interact... different relationships with different entities. I hope that helps.
Pat Adler: Yes, and the links are helpful.
USE CASE: Enable truly anonymous transactions such that the identity of the payee is not discoverable by payees, merchants, or payment processors.
Manu Sporny: Next use case is one that we decided in Web Payments Group not to put into Version 1.
Tim Holborn: Right to identity + persona… persona (psuedo anon) and ID (declared, etc.)
Manu Sporny: Basically, untraceable cash online. Rejected this use case bc not technically feasible. Runs afoul of regulatory.
Manu Sporny: True anonymity online -- for the credentials case, we support a certain amount of anonymity. Last week, discussed we need to be careful about "true anonymity" and "pseudo anon."
Manu Sporny: Cannot say we support true anonymity. Best we can say is we support pseudo-anonymity.
Dave Longley: We just support varying degrees of pseudo-anon
Manu Sporny: We'll come back to it -- Dave Longley's statement of supporting varying levels.
USE CASE: Jack (payer) wants to send Jill (payee) some money and asks Jill for a short, memorable payment identifier. Jill sends the payment identifier to Jack via an SMS message. Jack makes a payment using the short payment identifier; the payment processor translates the short payment identifier into a destination financial account for Jill.
Manu Sporny: For example, Jill could SMS text Jack the following message: Send $5 to ~JillJackson
Manu Sporny: Jack could put that into his payment client and "JillJackson" would be expanded to an identier.
Manu Sporny: Ripple Labs brought up this use case -- another use case, next in the list, concerns this.
Manu Sporny: Requires a new protocol for short identifiers. Should this be a Version 2 feature?
Manu Sporny: If we create this short payment identifier expansion mechanism...
Tim Holborn: About http?
Manu Sporny: No, about a new identifier on the Web for mapping to a new URI, potentially with a decentralized-hash-table back-end.
Evgeny Vinogradov: Version 1 can consider credential
Manu Sporny: Yes, Version 1 on basic identifiers. Version 2 can say, we can shorten those identifiers.
Manu Sporny: We're out of time
Evgeny Vinogradov: The SMS message, distinction is you're creating a short identifier from a long one. We need the long identifiers first, then we can choose how to shorten them later.
Manu Sporny: We need to discuss this more deeping to decide if we want to tackle this in the Version 1 work.
Manu Sporny: Needs to be generalized if any traction at W3C.
Manu Sporny: We are out of time. Same call, next week. Anything we should be aware of before the call next week?
Pat Adler: Best way to send feedback on the use cases?
Manu Sporny: Mailing list is best. There is a "respond to this message" link at the bottom of mailing list messages -
Manu Sporny: These are Tim's use cases. Do you mean the wiki use cases?
Manu Sporny: Mailing list is the best place. "Mail options" link will open your email client. You have to be in the community group before you can respond.
Manu Sporny: Thanks, everyone.