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

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

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 identity ✪

Manu Sporny: Far more accessible ✪

Pindar Wong: Fwiw note https://letsencrypt.org/ for late this year ✪

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 level ✪

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 PKI ✪

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 activities ✪

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 point. ✪

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: https://github.com/search?utf8=%E2%9C%93&q=filename%3Aid_rsa&type=Code&ref=searchresults ✪

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. ✪