W3C home > Mailing lists > Public > public-credentials@w3.org > March 2016

Verifiable Claims Telecon Minutes for 2016-03-15

From: <msporny@digitalbazaar.com>
Date: Tue, 15 Mar 2016 12:46:32 -0400
Message-Id: <1458060392521.0.17076@zoe>
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:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 15 March 2016 16:47:01 UTC