W3C home > Mailing lists > Public > public-credentials@w3.org > August 2015

Credentials CG Telecon Minutes for 2015-08-18

From: <msporny@digitalbazaar.com>
Date: Tue, 18 Aug 2015 12:56:38 -0400
Message-Id: <1439916998632.0.20537@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Matt Stone for scribing this week! The minutes
for this week's Credentials CG telecon are now available:


Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

Credentials Community Group Telecon Minutes for 2015-08-18

  1. Recruiting
  2. IMS Global Update
  3. Capabilities Document
  Manu Sporny
  Matt Stone
  Matt Stone, Richard Varn, Manu Sporny, Pindar Wong, Nate Otto, 
  Brendan Benshoof, Dave Longley, Andrew Rosen, David I. Lehn, 
  Laura Fowler

Matt Stone is scribing.

Topic: Recruiting

Richard Varn:  Prometric is a "no" on joining W3C

Topic: IMS Global Update

Manu Sporny:  Expect a full update next week after the conference

Topic: Capabilities Document

Manu Sporny:  Will review and introduce the details of the 
  expected/desired capabilities of the standard.  picking up where 
  we left off last week
Manu Sporny:  Web based PKI - allows individuals who don't own a 
  domain (most people) to participate and have control of their own 
Manu Sporny:  Far more accessible
Pindar Wong: Fwiw note https://letsencrypt.org/ for late this 
Nate Otto:  New/casual users may not follow best practices and 
  their key could get compromised -what do they do?
Manu Sporny:  Key lists "owner" and others who have "key 
  management" responsibility. you may be one of the "others" from 
  another device and have a way manage your key.
Nate Otto: Does this date based invalidation require some kind of 
  trusted timestamping mechanism on credentials?
Manu Sporny:  Financial industry uses dedicated hardware in 
  offline datacenters for key management at the highest security 
Pindar Wong: :)
Nate Otto: Yeah, I can certainly see trustworthy timestaming as a 
  use case for the multiple signatures on a credential mechanism.
Pindar Wong: Blockchain ?
Brendan Benshoof:  Will have to do work to convince people to use 
Manu Sporny:  Will have to hide it.
Matt Stone:  This gets to casual user managing their keys - if I 
  have 3 devices with computers/tablets - key for each one - how 
  much do I have to repeat that whole exercise of saying "I need 3 
  signatures to change anything"? [scribe assist by Manu Sporny]
Manu Sporny:  Expressing assumption/expectation that people will 
  use an identity provider
Dave Longley: The system is flexible; you choose the level of 
  security and convenience that works for you. Most people will 
  delegate key management to their identity provider.
Matt Stone:  Do identity providers exist today?
Manu Sporny:  Not today - no standard yet (that's what were here 
  today) would advocate for existing ID providers like G+, Facebook 
  etc would adopt
Manu Sporny:  Individuals could self-sign claims about 
  themselves, but nobody is going to trust that signature, because 
  it's not authoritative. If the US Government issues a credential 
  saying your name is James Dean, then people in the US would 
  likely trust it. [scribe assist by Nate Otto]
Manu Sporny:  Expect choice of identity providers, open source 
  and commercial
Manu Sporny:  Stakeholders can determine what types of providers 
  to trust
Pindar Wong: Thanks... I need to drop off now, looking fwd to 
  reading the minutes. tks all for an interesting call.
Manu Sporny:  App Integration - probably most open to 
  interpretation.  user should be able to grant system access to 
  your credentials
Manu Sporny:  .... For non-interactive manner
Manu Sporny:  Need more focus to describe what this really means 
  to us
Manu Sporny:  Privacy-enhanced Sharing:  share a credentiaal in a 
  way that prevents identity provider to track you and your 
Dave Longley:  Similar to SSO on the web like g+ or twitter, so 
  the SSO provider knows where your logging it.  this concept of 
  privacy isn't support in SSO today
Dave Longley:  A key desire it to prevent/block identity 
  providers from knowing who the credential is shared with or who's 
  verifying it
Manu Sporny:  Unlike other capabilities, we're taking a 
  philosophical stance here
Manu Sporny:  Protocol would be setup so it's impossible for ID 
  providers to know where a credential was shared
Brendan Benshoof:  Need a way to unravel the privacy-enhanced 
  sharing for things like law enforcement - we need another bullet 
Dave Longley: "Regulatory compliance"?
Brendan Benshoof:  Need to include the concept of regulatory 
  requirements for privacy in our capability
Andrew Rosen: +1 Regulatory compliance
Matt Stone: +1 Regulatory compliance
Manu Sporny:  Many of the credential and finance cases exist in 
  industries/ecosystems that are heavily regulated
Manu Sporny:  Credential portability - should be able to move 
  credentials between identity providers on demand
Andrew Rosen: +Q Can we do anything more sophisticated than a 
  credential TTL?
Manu Sporny:  Credential revocation: support a way to revoke a 
  credential if issued erroneously
Manu Sporny:  All data is "linked data" with an id that lives on 
  the web somewhere, which is verified in realtime.
Matt Stone:  Revocation, in reality, happens much less than 
  updating a credential - how do you have living data? [scribe 
  assist by Manu Sporny]
Nate Otto: +1 Stonematt Updating / renewing a credential happens 
  far more often than revoking credentials in practice.
Brendan Benshoof:  How do we make it simple for issuers to manage 
  this kind of technical capability when they're historically so 
  bad at it?
Manu Sporny:  There will be licensed technology provides.  expect 
  the verification/validation app to be simple to host
Manu Sporny:  Responding to stonematt... since this is "linked 
  data" the credential could be fairly short lived and be linked 
  back to the issuer for details OR may have a "refresh" link with 
  update data
Nate Otto: In the news today about PKI: Here's a bunch of 
  people's private SSH keys published publicly on GitHub: 
Matt Stone:  This is a more sophisticated approach/solution than 
  the simple verification url in the previous response.  Benefit - 
  the system is very flexible in the way it can be deployed.
Andrew Rosen: No questions. Thanks!
Andrew Rosen: We managed to sneak a lot of those in.
Received on Tuesday, 18 August 2015 16:57:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:25 UTC