- From: <msporny@digitalbazaar.com>
- Date: Tue, 15 Mar 2016 12:46:32 -0400
- To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Brian Sletten for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:
http://w3c.github.io/vctf/meetings/2016-03-15/
Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).
----------------------------------------------------------------
Verifiable Claims Telecon Minutes for 2016-03-15
Agenda:
https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Mar/0043.html
Topics:
1. Draft Charter Proposal
2. Use Cases Document
3. Card for AC Meeting
4. Vocabulary changes - Issuer, Curator, Inspector
Resolutions:
1. Integrate as much feedback as possible before 3pm today and
send the editor's draft charter and use cases out for informal
review to the interviewees, the survey respondents, and the W3C
Advisory Committee.
Organizer:
Manu Sporny
Scribe:
Brian Sletten
Present:
Brian Sletten, Manu Sporny, Tim Holborn, John Tibbetts, Shane
McCarron, Dave Longley, Nate Otto, Daniel C. Burnett, Carla
Casilli, Matt Stone, Gregg Kellogg, Rebecca Simmons, Eric Korb,
Jason Weaver, Peter Hofman, David Ezell
Audio:
http://w3c.github.io/vctf/meetings/2016-03-15/audio.ogg
Brian Sletten is scribing.
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.
Topic: Draft Charter Proposal
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."
Topic: Use Cases Document
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]
PROPOSAL: Integrate as much feedback as possible before 3pm
today and send the editor's draft charter and use cases out for
informal review to the interviewees, the survey respondents, and
the W3C Advisory Committee.
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)
RESOLUTION: Integrate as much feedback as possible before 3pm
today and send the editor's draft charter and use cases out for
informal review to the interviewees, the survey respondents, and
the W3C Advisory Committee.
Manu Sporny: Anything else on draft use cases before we move on?
Topic: Card for AC Meeting
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
Topic: Vocabulary changes - Issuer, Curator, Inspector
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
Term = Random(Select(manager, curator))
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
+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 :)
Received on Tuesday, 15 March 2016 16:47:03 UTC