Manu Sporny: Same agenda as last week. We need to discuss the Draft Charter and Use Case documents. We need to discuss if we are going to hand out a card next week and if we are ready to go. ✪

Tim Holborn: I just dialed in ✪

Manu Sporny: We need to make some decisions about names. (Issuer, Curator, etc.) The end of the call is going to be a bike shedding exercise. ✪

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/charter/vcwg-draft.html ✪

John Tibbetts: Now I'm in ✪

Manu Sporny: We have had a really healthy amount of review. Thank you for everyone who did a review. We still have comments streaming in. The hope is to keep editing the editor's draft but we need to send it out at 3PM today. ✪

Shane McCarron: (3PM Eastern) ✪

Manu Sporny: The Advisory Committee will do an initial review. ✪

Manu Sporny: There have been some deep questions asked about the draft charter proposal, but are there any other questions and comments? How do people feel about the draft charter proposal? Is it ready to circulate for informal review? ✪

John Tibbetts: Good to go as far as I'm concerned ✪

Dave Longley: +1 For ready for informal review ✪

Manu Sporny: A lot has changed in the last week. ✪

Manu Sporny: http://w3c.github.io/webpayments-ig/VCTF/charter/vcwg-draft.html ✪

Shane McCarron: I am not afraid to circulate it for informal review. But thank you for making LOTS of changes in response to people. ✪

Manu Sporny: Let me be more clear about what has changed. ✪

Manu Sporny: The Problem Statement hasn't been changed much, mostly editorial. Matt Stone had asked us to tie the problem statement to the goals. That has been done. ✪

Manu Sporny: What we do now is take each bullet from the problem statement and say this is a goal. This is what we are trying to address. ✪

Manu Sporny: We can't too much in the Problem Statement without upsetting people who have already signed off on it. ✪

Manu Sporny: The Goal section can be modified as we see fit. The Deliverables follow the goals for at least the first stage. ✪

Manu Sporny: The Security/Privacy section has been updated to flow more easily. The Internationalization section has been added. ✪

Nate Otto: +1 On 4.1 deliverables ✪

Manu Sporny: Deliverables (4.1): previously we had only planned to deliver data model but now it says we are producing a core vocabulary as well. ✪

Tim Holborn: Do we vote on proposed changes in the Community Group? ✪

Manu Sporny: The documents are under control of the Web Payments IG, but if the VCTF says we have consensus to add X, I think that would carry a lot of weight. [scribe assist by Dave Longley] ✪

Tim Holborn: There are some privacy and data access rights that were originally discussed but may have been dropped. I don't want the timeline to prevent things that should be in from being excluded. ✪

Dave Longley: We have sections on covering security and privacy. We should be able to cover those things in a WG. ✪

Manu Sporny: Our window for updating the document is end of May. That's when we expect to have all comments in and have the document updated. ✪

Dave Longley: "The design of any data model and format should guard against the unwanted leakage of such data." + a deliverable of core vocabs = we are covered ✪

Manu Sporny: If the comments drop off by the end of April, we can decide we can go forward. You still have four weeks. ✪

Shane McCarron: There is also a couple of use cases that explicitly require the ability to only disclose the attributes that are needed for a transaction. ✪

Manu Sporny: Any other comments on the charter? Anything that is missing that clearly needs to be put in there? ✪

Shane McCarron: But I agree that there is potential for leakage / unintentional disclosure of traceable information. ✪

Dave Longley: Also: "From a privacy perspective it is important that information that is intended to remain private is handled appropriately." ✪

Shane McCarron: We got some feedback on the document. It was all reasonable editorial stuff. We got a set of questions from Ian that I attempted to address. ✪

Shane McCarron: https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Mar/0012.html ✪

Manu Sporny: Use cases are here: http://w3c.github.io/webpayments-ig/VCTF/use-cases/ ✪

Shane McCarron: He pointed out some wording issues and inconsistencies. He also asked a question about a fundamental of a tenet of the requirements that we put forth in the Use Cases. I wanted to touch on it here to see if I have the right understanding. ✪

Shane McCarron: [Reads from the Jane alcohol purchase use case] Ian: "This seems hard to handle in general. How do you allow people to ask questions that allow people to ask arbitrary questions about arbitrary attributes." ✪

Nate Otto: We cannot expose only certain attributes of a claim without invalidating the signature ✪

Manu Sporny: That's not necessarily true, ottonomy - but we don't want to use the tech that allows for that, imho. ✪

Nate Otto: Ok, granted. :) ✪

Shane McCarron: I don't think this is a Use Case issue, but do we want to allow individual attributes to be asked for and how does that impact the signature/verifiability of the claims? ✪

Manu Sporny: Camenisch-Lysyanskaya Signature ✪

Manu Sporny: A claim could be a individual statement, but there are some other technologies like CL Signatures that allow this. ✪

Manu Sporny: S/Manu: A Claim/Dave Longley/ ✪

Tim Holborn: Yes. We want this. ✪

Tim Holborn: Tim Holborn... ✪

Nate Otto: I also assumed for this liquor store use case, the claim they have in hand is a plain "over 21" claim, not a specific birthdate claim. ✪

Daniel C. Burnett: While we may want requirements about transformability of claims which is separate from composability. I always thought they would get a claim of being over a specific age. We can discuss transformability separately. ✪

Tim Holborn: +1 ✪

Shane McCarron: +1 It was intentionally ambiguous ✪

Carla Casilli: Are we talking about a claim that someone is of legal age or that someone is of a certain age? Because driver's licenses actually reveal true age. (May or may not be worth discussing here.) ✪

Manu Sporny: CarlaCasilli, we're talking about both :) ✪

Dave Longley: I liked that that UC was intentionally ambiguous. I didn't think transformability was required. I thought that it could be able to comply with a certain regulation without revealing extra information. How it is done isn't as important that a specific claim can be made. ✪

Daniel C. Burnett: My point was that the use case does not necessarily mandate transformability, which Ian seemed to have assumed ✪

Manu Sporny: Agreed, Dan. ✪

Dave Longley: +1 Burn ✪

Shane McCarron: I don't think we should debate the details of the technology today. It was intentionally ambiguous. I just wanted to confirm the requirement. Sounds like it was a strong 'YES'. ✪

Daniel C. Burnett: But it sounds like we want transformability anyway :) ✪

Nate Otto: Can you clarify the question about what the requirement that you feel is a "very strong yes?" ✪

Dave Longley: +1 Shane, it's a requirement, Ian just assumed a bit too much about the potential capability for providing for that requirement ✪

Nate Otto: Sorry: What is the requirement at hand? ✪

Shane McCarron: I am open to changes to the document. We want to keep it tight on the health care, education and financial verticals so we have examples for each of them. I got a nice UC from JohnTib that I have inserted. ✪

Daniel C. Burnett: I should have said transformability/subsettability ✪

Manu Sporny: Do we require transformability? Or composability? Or subsettability? or all three? <--- ottonomy ✪

Dave Longley: +1 Transformability/subsettability is cool ... not sure it's a requirement though ... it's hard. ✪

Manu Sporny: Yes, very hard to do ✪

Dave Longley: *Very hard* ✪

Shane McCarron: I think we're in a pretty good space here. I am open for additional documents on this document. I want to focus on the other document, the vision document, the extended use case document. ✪

Dave Longley: (To do in a nice, extensible way) ✪

Nate Otto: If the requirement we're talking about is "recipients should be able to transform claims to display only attributes of those claims they want to share", I think this is not a good requirement to address. ✪

Daniel C. Burnett: Composability was very clearly in the extended use cases, but not necessarily transformability or subsettability ✪

Shane McCarron: We want to make sure that nothing that happens in the initial phase precludes the vision. ✪

Manu Sporny: And fraught with minefield of accidentally exposing PII or accidentally providing linkability. ✪

Nate Otto: 4.3.3 [scribe assist by Shane McCarron] ✪

Dave Longley: It's easier to do with boolean attributes -- but there are a lot of size/processing time constraints regardless w/the current tech. ✪

Manu Sporny: One thing that I don't think we have done yet with the UC document is map the use cases that map back to the goals and problem statement. Someone needs to do a review. ✪

Matt Stone: Transforming a claim to another claim may also produce a claim that mis-represents the intention and scope of the original verifiable claim ✪

Brian Sletten: I will do that. ✪

Nate Otto: 4.3.3 Pseudo-anonymity gets my +1, and I'm ok with some ambiguity there, but I do not think we should add a requirement that claims be transformable. Thanks for looking up the section and clarifying that it was the one already in the document. ✪

Manu Sporny: We are talking about a lot of cryptographic things. Each one is a separate topic. Mashing them all together becomes fantastically difficult to do. We've had many debates about pseudoanonymity and unlinkability and they are by far the smallest amount of data. I am very much in the privacy camp, but these problems do not have simple solutions. ✪

Shane McCarron: Unless the key is stored remotely or is dynamically generated each request and the credential is never actually transmitted. ✪

Daniel C. Burnett: FYI, I am not arguing at all for transformability. I was actually arguing that Ian assumed it when it was not necessary for the specific use case. ✪

Manu Sporny: There are always tradeoffs. We want these things to be there, but we should be realistic about what is achievable. ✪

Dave Longley: I prefer us to put use cases in there and then let a WG figure out how to solve them, not say "transformability" is a hard requirement ✪

Daniel C. Burnett: Yes, although personally I would like pseudo-anonymity and unlinkability everywhere, as long as they are possible for the use cases where it is demanded it does not need to be present for all use cases (and is not appropriate for all use cases) ✪

Tim Holborn: I don't want to hijack the conversation but I have done work in this space. There are boundaries where contract law applies (to a product example), but it does need to be supported by technology. ✪

Shane McCarron: I agree with Tim. But because we are talking about standards... even with licensing so what? Someone else could make their own implementation, not pay a fee, and then exploit. ✪

Daniel C. Burnett: +1 Dlongley ✪

Nate Otto: Concern on the second scenario on 4.3.3: "He provides a credential that verifies his name and address...He [claim recipient] further marks the disclosure as expiring in 30 days - he does not want his information verifiable after that time." The recipient marking a claim as expiring when forward-sharing a credential that has been signed potentially without that expiration built in. I think this sentence may complicate the pseudo-anonymity use case and ✪

Nate Otto: Make it much harder to implement. ✪

Shane McCarron: +1 To not including transformability as a term. Atomic claims, or separately signed attributes within an aggregated claim are fine. ✪

Manu Sporny: I am just raising this as a reminder that we want to put these in the use cases document, but not have to commit to solving these problems today. ✪

Dave Longley: We need to let a WG take a look at this. You can make something unlinkable but this can be exploited for fraud. I think we should put some use cases in there and see what a WG can do to solve it. ✪

Tim Holborn: Another one that seems important is portability (e.g. moving from one back to another). This requires an update mechanism on the URIs which may impact unlinkability. ✪

Shane McCarron: I note that there is no use case that represents that ✪

Nate Otto: 4.2 Revoking claims is about the checking account case Tim mentions. ✪

Manu Sporny: We have some support for portability. The second goal addresses this. Does that meet the portability goal? ✪

Tim Holborn: I was trying to address the need to avoid vendor lock-in. ✪

Dave Longley: I think we cover vendor lock-in in the problem statement and the ability move verifiable claims from one service provider to another. ✪

Shane McCarron: It's not covered in the Use Cases. ✪

Manu Sporny: We need to put that in there. ✪

Dave Longley: +1 Let's add a scenario to the use cases for that ✪

Manu Sporny: This is good. We found a gap. We need to fill it before we send it out. ✪

Nate Otto: https://docs.google.com/document/d/1GySrTXAYpwa4vDPsGE3BMA42FwIAqAyLGigKuKUTGks/edit# There is a portability entry in this old use cases document ✪

John Tibbetts: Have to leave early for another meeting. tnx all. ✪

Shane McCarron: Which section should I put it? There was a management section. ✪

Tim Holborn: International migrations (from one country to another) might work. ✪

Nate Otto: +1 "Managing Claims" ✪

Carla Casilli: If we're talking about data ownership, there should be a section that focuses on the credential owner ✪

Carla Casilli: Holder ✪

Carla Casilli: And that would mean subject of credential ✪

Carla Casilli: I hear you. ✪

Carla Casilli: Yep. ✪

Manu Sporny: Carla, without Use Cases and text surrounding it, it will be hard to get it in in time. Can you send something to the list? ✪

Shane McCarron: What's the best way to do this? [scribe assist by Carla Casilli] ✪

Dave Longley: No concerns from me ✪

Shane McCarron: CarlaCasilli, email to shanehalindrome.com feels safest to me ! ✪

Daniel C. Burnett: No concerns ✪

Shane McCarron: Great, will do. thanks. [scribe assist by Carla Casilli] ✪

Gregg Kellogg: +1 ✪

Daniel C. Burnett: +1 ✪

Dave Longley: +1 ✪

Matt Stone: +1 ✪

Carla Casilli: +1 ✪

Shane McCarron: +1 ✪

Tim Holborn: +1 ✪

Nate Otto: +1 ✪

Manu Sporny: +1 ✪

Rebecca Simmons: +1 ✪

Shane McCarron: (I have good content for a portability use case now) ✪

Manu Sporny: Anything else on draft use cases before we move on? ✪

Manu Sporny: During the last meeting we asked if we should have a handout. dezell suggested a business card with a link and a QR code requesting people review the draft charter. ✪

Nate Otto: +1 Card ✪

Daniel C. Burnett: +1 Card ✪

Tim Holborn: +1 ✪

Shane McCarron: I love this idea. work with me on it? I have a vendor here. ✪

Matt Stone: +1 ✪

Manu Sporny: I will make them by Friday and give them to dezell and ShaneM. Any issue with the card? ✪

Carla Casilli: +1 And they make great party favors. ;) ✪

Daniel C. Burnett: Wish I could be there to see the reaction :) ✪

Shane McCarron: Want to hand them out at LibreWorld? ✪

Matt Stone: Will you mail one to each of us? :) ✪

Shane McCarron: Lol ✪

Shane McCarron: Libreplanet I mean ✪

Manu Sporny: We had a discussion a while ago on terminology. Sounds like folks are happy with Issuer and Holder. ✪

Dave Longley: There is also "Subject" ✪

Manu Sporny: There is also "Subject" the thing the claim is about. People seem ok with that. ✪

Matt Stone: So subject and holder may be the same? ✪

Manu Sporny: There are two things we weren't sure about. The entity that stores credentials on behalf of the Holder. We have been calling that the Curator. ✪

Dave Longley: Usually the same, but not always. ✪

Matt Stone: That was the dog example, right? ✪

Shane McCarron: Ian did not like the name curator. btw. ✪

Nate Otto: -1 Curator. I'd prefer "management service", "vault" ✪

Carla Casilli: -1 On the term curator. ✪

Manu Sporny: Where the Credential is stored is the Identity Provider which is confusing to the OpenID/SAML community. ✪

Carla Casilli: Aggregator ✪

Carla Casilli: ? ✪

Matt Stone: -1 Onl vault +1 on curator ✪

Shane McCarron: Claim Store? ✪

Shane McCarron: No. ✪

Daniel C. Burnett: Stone, yes, it was the dog/car example ✪

Shane McCarron: -1 To identity provider. that uses the word identity ✪

Nate Otto: "Curator" has two main definitions. 1 is "keeper" which is pretty accurate, but I think the second definition around "selecting" is stronger in current understanding, and the function of this entity is not selecting. It is just respecting user's selections. ✪

Carla Casilli: Agreed with ottonomy's point ✪

Manu Sporny: We've talked about vaults, but it's not necessarily a vault. We've talked about curator. We have to have the Curator discussion. The organization that consumes the Credential with have called Credential Consumer. We've discussed Inspector/Acceptor. ✪

Nate Otto: +1 "Inspector" solves some problems with "consumer"/"acceptor" ✪

Dave Longley: "Credential Agent" or "Claims Agent" could replace "curator" ✪

Manu Sporny: Two discussions we need to have because we are putting this language in the Use Cases and it gets harder to change. ✪

Carla Casilli: Is it possible that there is an inspector and a consumer? ✪

Matt Stone: Me too - i'm more "neutral/positive" on curator. i think the systems that stores claims is more passive than what a curator "does" ✪

Shane McCarron: I like requestor too... (instead of consumer). ✪

Manu Sporny: Let's discuss Vault/Identity Store/Curator/Aggregator: ✪

Dave Longley: Requestor is too ambiguous, could be the subject/future holder "requesting" a claim from an issuer ✪

Dave Longley: Agent of some sort ✪

Dave Longley: For curator. ✪

Manu Sporny: Choices: identity provider / claim store / curator ✪

Shane McCarron: -1 To Identity Provider (easily confused with issuer; has word identity in it) ✪

Eric Korb: -1 Identity provider ✪

Shane McCarron: -1 Requestor since consumer might have been given the claim without requesting it [scribe assist by Daniel C. Burnett] ✪

Eric Korb: +1 Curator ✪

Manu Sporny: Choices: identity provider / claim store / curator / agent / manager ✪

Daniel C. Burnett: +1 Claim store ✪

Carla Casilli: +1 Manager ✪

Nate Otto: +1 Vault, -1 identity provider/store, -1 curator, +1 aggregator, +1 credential agent, +1 credential manager ✪

Matt Stone: -1 Identity provider ✪

Shane McCarron: Burn, good point ✪

Eric Korb: -1 Agent could be browser ✪

Shane McCarron: +1 Manager (claim manager) ✪

Jason Weaver: +1 Curator ✪

Manu Sporny: +1 Curator (for me) ✪

Shane McCarron: +1 Agent (claim agent) ✪

Rebecca Simmons: What about credential provider? ✪

Matt Stone: I like "store" over "manage" or "curate" because the action seems more correct ✪

Dave Longley: -1000 Identity provider, +meh for claim store, +0 curator, +1 agent, +1 manager ✪

Gregg Kellogg: +1 Manager, +1 credential agent, +1 credential manager, +1 claim agent, +1 claim manager ✪

Eric Korb: I feel "credential agent" would be distinct enough from "user agent" (browser) [scribe assist by Nate Otto] ✪

Eric Korb: -1 Manager could be a person. ✪

Daniel C. Burnett: Agree with stone. storing is exactly what is happening ✪

Dave Longley: Agree with Shane ✪

Carla Casilli: Agreed with Shane ✪

Dave Longley: Also was thinking storage, but know others won't. ✪

Matt Stone: +1 Store; +1 curate; -1 manager; -1 agent ✪

Tim Holborn: I've been reviewing http://www.rogerclarke.com/ID/IdModel-1002.html as was highlighted to me this week, but haven't had time to go through it properly ✪

Brian Sletten: Is the spread on reactions indicative of intertwingled ideas? ✪

Eric Korb: Ottonomy, "agent" could be one's behalf - I'm so,so on that ✪

Daniel C. Burnett: Hmm, agree that noun usage of store could be a problem ✪

Carla Casilli: -1 Curator ✪

Peter Hofman: On Wndows its certificate store ✪

Daniel C. Burnett: -1 Curator, manager, agent ✪

Eric Korb: Korb likes curator ✪

Manu Sporny: Choices: manager, curator ✪

Tim Holborn: "Entification. The association of data with a particular entity depends on the acquisition of an entifier such as a phone's IMEI, a processor-id or a human biometric. This process is usefully described as entification." ✪

Carla Casilli: Curator is an incredibly popular word in the edu world for selecting specific content ✪

Nate Otto: +1 Manager ✪

Eric Korb: Manager could be a person ✪

Shane McCarron: +1 Manager ✪

Gregg Kellogg: +1 Manager ✪

Tim Holborn: +1 Curator ✪

Eric Korb: + Curator ✪

Manu Sporny: +1 Curator ✪

Carla Casilli: +1 Manager ✪

Jason Weaver: +1 Curator ✪

Matt Stone: +1 Curator ✪

Dave Longley: +1 Curator, terminology is unique ✪

Shane McCarron: Manator ✪

Carla Casilli: Manator!!! ✪

Shane McCarron: Change my vote ; +1 curator. it us unique ✪

Daniel C. Burnett: Synonyms for vault: bag, barrel, basket, belly, bin, bladder, bottle, bowl, box, bucket, cabinet, can, case, cask, chest, closet, container, crate, cup, cupboard, decanter, drawer, drum, flask, holder, jar, jug, ladle, locker, pocket, pot, pouch, purse, receptacle, repository, reservoir, sack, shelf, stomach, storage, suitcase, tank, tray, trunk, vat, wallet. ✪

Eric Korb: Loop() ✪

Rebecca Simmons: Why is not an "issuer" of the credential? ✪

Shane McCarron: Claim repository? ✪

Daniel C. Burnett: +1 Curator if absolutely necessary ✪

Dave Longley: +1 To valuable things idea ✪

Shane McCarron: Curator ALSO feels like it could have some intelligence ✪

Brian Sletten: Manager = consensus agent ✪

Carla Casilli: But the curation should be on the holder's part, and the credential repository org is not the curator but rather the recipient of the curation ✪

Dave Longley: My biggest plus for curator is its uniqueness ... and it could become uniquitous -- as Shane says :) ✪

Eric Korb: Curator implies management ✪

Brian Sletten: Carla, this is why I thought we may have tangled concepts here. ✪

Daniel C. Burnett: Why not repository? several irc comments have used exactly that word ✪

Carla Casilli: Agreed, bsletten_ ✪

Nate Otto: Oh, the reason I was -1 on curator was because I would prefer to think of the service I use to store my credential as more of a dumb bucket. Even though I would probably build some intelligence into my bucket when I build one. ✪

Carla Casilli: Repository = +1 ✪

Gregg Kellogg: A curator might dispose of expired credentials (otherwise, what’s to curate?) ✪

Daniel C. Burnett: Yes, I wish we had repositor :) (creating a noun from repository) ✪

Rebecca Simmons: Check out this diagram http://w3c.github.io/webpayments-ig/VCTF/use-cases/#how-a-verifiable-claim-might-be-created [scribe assist by Shane McCarron] ✪

Dave Longley: Credential archive ... archivist ✪

Dave Longley: Credential depot ✪

Matt Stone: -1 Governor ✪

David Ezell: Governor feels like something that slows things down ;-) [scribe assist by Shane McCarron] ✪

Matt Stone: Credential bureau ✪

Manu Sporny: Choices: manager, curator, repository ✪

Daniel C. Burnett: +1 Repository, -1 manager ✪

Dave Longley: -1 Manager ✪

Nate Otto: +1 Manager, 0 curator, +1 repository ✪

David Ezell: +1 Curator ✪

Manu Sporny: +1 Curator, -1 manager, +0 repository ✪

Matt Stone: -1 Manager; 0 curator; +1 repository ✪

Gregg Kellogg: +1 Manager, -1 curator, +1 repository ✪

Carla Casilli: + 1 Repository, -1 curator, +1 manager ✪

Shane McCarron: +1 Repository, -1 manager, 0 curator ✪

Dave Longley: +1 Curator, +1 repository ✪

Eric Korb: +1 Curator ✪

Tim Holborn: -1 Manager +1 curator ✪

Jason Weaver: -1 Manager, +1 curator, +1 repository ✪

Matt Stone: +1 ShaneM ✪

Dave Longley: I do like the alliteration of "credential curator" :) ✪

Tim Holborn: +1 Repository ✪

Brian Sletten: Eventual consistency and consensus protocols in action. ✪

Eric Korb: -1 ✪

Eric Korb: Digital curation is the selection, preservation, maintenance, collection and archiving of digital assets. Digital curation establishes, maintains and adds value to repositories of digital data for present and future use. This is often accomplished by archivists, librarians, scientists, historians, and scholars. ✪

Eric Korb: Digital curation - Wikipedia, the free encyclopedia ✪

Tim Holborn: How about bank? ✪

Tim Holborn: Credential bank ✪

Eric Korb: Thanks for that. [scribe assist by Shane McCarron] ✪

Tim Holborn: Credential account? ✪

Matt Stone: +1 Manu comment ✪

Eric Korb: +1 Accreditrust see themselves as a "curation curator" ✪

Dave Longley: Sounds crude ... not sure i'd want to put my credentials in a repository :/ ✪

Eric Korb: -Curation ✪

Carla Casilli: Thanks! ✪

Dave Longley: Did we? ✪

Dave Longley: No. but out o time [scribe assist by Shane McCarron] ✪

Daniel C. Burnett: Marketing: "yes, we are better than a repository, we are curators" . Makes perfect sense. ✪

Manu Sporny: No call next week, but we'll meet the following week to discuss how the meeting went. ✪

Nate Otto: With Concentric Sky hat on, we're fine with repository as a generic term, but we'd add in the "intelligence" as a upsell to our repository option and into its branding. (btw, /me is Nate Otto, usually use a different nick for this channel) ✪

Daniel C. Burnett: Sorry, my comment sounded snide but wasn't meant to be. i think this is the right path. ✪

Manu Sporny: Didn't take your comment as snide, Dan :) ✪