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

Re: Credentials CG Telecon Minutes for 2015-08-11

From: Steven Rowat <steven_rowat@sunshine.net>
Date: Wed, 19 Aug 2015 20:48:05 -0700
To: public-credentials@w3.org
Message-ID: <55D54DF5.8030207@sunshine.net>
On 8/18/15 7:48 AM, msporny@digitalbazaar.com wrote:
> Thanks to Dave Longley for scribing this week! The minutes
> for this week's Credentials CG telecon are now available:
>
> http://opencreds.org/minutes/2015-08-11/

I get 404 not found for this link, and for the 2015-08-18 one also.

I also tried the supposedly same links given from here where it says 
"available in the archive":

https://www.w3.org/community/credentials/

and same result.  :-(

The week prior to this (...08-04) links correctly.

Does this happen to anyone else? Or is it just my configuration somehow?

Steven


>
> 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-11
>
> Agenda:
>    https://lists.w3.org/Archives/Public/public-credentials/2015Aug/0022.html
> Topics:
>    1. Introduction to Annie Jenssen
>    2. Recruiting
>    3. Roadmap
>    4. Credentialing Capabilities and Current Proposal
> Organizer:
>    Manu Sporny
> Scribe:
>    Dave Longley
> Present:
>    Dave Longley, Manu Sporny, Annie Janssen, John Tibbetts, Richard
>    Varn, Eric Korb, Brian Sletten, Matt Stone, Brendan Benshoof,
>    Nate Otto, Rob Trainer, David I. Lehn
> Audio:
>    http://opencreds.org/minutes/2015-08-11/audio.ogg
>
> Dave Longley is scribing.
> Manu Sporny:  We're adding one agenda item which is an
>    introduction by Annie Janssen from Parchment.
> Manu Sporny:  Any other changes?
>
> Topic: Introduction to Annie Jenssen
>
> Annie Janssen:  Hi, Annie Jenssen - product manager at Parchment.
>    Parchment is primarily an e-transcript company, we have a
>    conusmer company - parchment.com. We have lots of highschools
>    using transcripts - I manage consumer-side of things. Website
>    where highschoolers can log on. Right now adding other credential
>    types. We've partnered with CLA so students can order their
>    credentials, diplomas, certifications, other types of academic
>    credential.
> Manu Sporny:  Great, welcome to the group. Are you joining the
>    group long term or are you just joining in? What do you hope to
>    get out of the group over the next couple of meetings?
> Annie Janssen:  I'm joining the group - joining community groups
>    to get an idea of what's going on in the Credential landscape.
>    Working on consumer side, want to make sure I'm in the loop with
>    everything that's going on in the credentialing world. [scribe
>    assist by Manu Sporny]
> Manu Sporny:  Awesome. Any other questions for Annie before we
>    move on?
> None
>
> Topic: Recruiting
>
> Manu Sporny:  We need to another round of pings to make sure
>    people have seen the recruiting questionnaire and they will it
>    out.
> Manu Sporny:  The other thing that is happening right now is this
>    case that we're making to W3C that credentials are worth doing.
>    The first two blog posts are done.
> Manu Sporny:  We've got a bunch of background material in the
>    second post that strengthens the arguments made in the first
>    post.
> Manu Sporny:  I've circulated this with people that will be on
>    the call to discuss in the next couple weeks.
> Manu Sporny:  If you can send me feedback so I can make
>    changes/updates to it that would be great. Initial response from
>    W3C staff has been that it's good and they are appreciative of
>    all the background research that went into it.
> Manu Sporny:  For those joining late, we've got another 60 orgs
>    that haven't responded yet and we need to ping those.
> Manu Sporny:  We need Matt Stone, John Tibbetts, Eric, to re-ping
>    people on the list.
> Manu Sporny:  We need responses to the questionnaire.
> Manu Sporny: This is the form that we're asking organizations to
>    fill out:
>    https://docs.google.com/forms/d/1GQJg-SQ6vQ0iUdCFrA5WWcja7bpQv6U5ryLXYSzeRcI/edit
> John Tibbetts:  I'll be seeing some of these people next week. I
>    can talk to them then.
> Manu Sporny:  That would be fantastic.
> Manu Sporny:  Any other updates on recruiting?
> Richard Varn:  I got a phone call, Gary from ETS and I, and we
>    talked with Accenture and they'll run it up the poll and get back
>    to us about joining. They were worried about time commitment and
>    I told them to not worry about committing a technical expert for
>    every meeting, etc.
> Richard Varn:  We met with IMS Global and met with someone who is
>    running their credential effort there. They are having
>    initiatives about competency based education another on
>    credentials. It was "Carla Casilli".
> Richard Varn:  She's leading the work there now.
> Manu and korb had presented to Carla.
> Carla is have a session at IMS next week on Tuesday.
> Richard Varn:  She's inviting the right people, etc. She
>    mentioned you've talked with her.
> Manu Sporny:  Eric and I did a presentation with her around July
>    9th.
> Richard Varn:  They will kick off their calls and discussions
>    soon.
> Manu Sporny:  Thanks for the update Richard, fantastic news on
>    Accenture.
>
> Topic: Roadmap
>
> Manu Sporny:  There's one huge multimillion dollar tech company
>    I'm speaking with right now -- they've said they are interested
>    in the work, hopefully they'll join and I can talk about them
>    soon.
> Eric Korb:  I've been working on vocabs
> Brian Sletten:  I was planning on working on the Use Case
>    document this week.
> Manu Sporny:  Eric has been working on the glossary.
> Manu Sporny:  I need to resync docs.
> Manu Sporny:  The last document, the Capabilities, kind of sprang
>    out of the detailed blog post, the credentials retrospective. One
>    of the things the W3C staff asked for was a list of capabilities
>    that an open credentials system should have. Because we hadn't
>    written that list down yet, we were able to chat with a few of
>    you offline and come up with that list. The credentials
>    retrospective post above in IRC has a list of goals for a
>    credentials ecosystem and a list of capabilities for that system.
> Manu Sporny:  There are things like using an extensible data
>    model, ensuring that multiple market verticals can create their
>    own credentials without central coordination. Web-based PKI and
>    digital signatures. These are all capabilities we believe the
>    system should have. We analyze other existing technology matches
>    those capabilities or not.
> Manu Sporny:  Quite a bit of work has gone into that and I think
>    that will be the first very rough draft of those things split out
>    by area.
> Manu Sporny:  4 Bigs areas: Issuing, storing, managing lifecycle,
>    and consumption of credentials.
> Eric Korb:  @Brian what doc file are you using? Happy to
>    contribute a few use cases.
> Manu Sporny:  We've got features underneath that that we can get
>    from the blog post.
> John Tibbetts:  I have one suggestion, about the blogs. I thought
>    the post on successes and failures was compelling. But I think
>    what's missing (but not from this document, this is about "what's
>    out there")... if there was a follow on document that says
>    "Here's how the technologies we're working on would deal with
>    this." A sentence or two about what parts of the technology would
>    address the capabilities and so forth would be good.
> Manu Sporny:  I absolutely agree, but let me give you some
>    background. When I talked to the W3C staff members, and the best
>    way to address it is to say the problem exists, list the
>    problems, then go into all the things people are scared about
>    when talking about credentials, loss of privacy, lack of
>    anonymity, problem solved before, etc. Then talk about all of the
>    things that have been tried before and why they aren't an
>    acceptable solution ... and then leave it there. Don't talk about
>    the solution the CG has created yet because we need to first get
>    people on board that there is a problem and that we need a
>    solution. They've got products, etc. that need these things. Once
>    people are on the same page for the basic philosophy for what
>    we're trying to do. Then we can talk about how the proposal we
>    have, at least from the CG, addresses those capabilities.
> Manu Sporny:  The W3C staff thought that getting into the CG's
>    solution too quickly that people would fixate on that and it
>    would detract from getting consensus on the high level vision and
>    capabilities.
> Manu Sporny:  I will try and write the CG solution blog post and
>    so folks like you can take that post and show it as a proposed
>    solution.
> Eric Korb:  Ek feedback on blog post: Do we need to distinguish
>    between identity and credentials? Is there one?
> Manu Sporny:  Yes, there is a strong distinction that we make in
>    the technical work between identity and credentials. We've also
>    been trying to be very careful to not say that we're trying to
>    solve the identity problem on the Web because it's got huge
>    scope. We're just trying to talk about issuing, storing,
>    consuming credentials.
> Eric Korb:  Concern that W3C sees it as the same
> Manu Sporny:  Maybe we can try to make that more clear in the
>    blog post.
> Manu Sporny:  We're going to have to try and make that point
>    clear to them.
> Nate Otto: -1 To verifiable attributes
> Manu Sporny:  They've also said they don't want to call it
>    "credentialing" and instead use "verifiable attributes" because
>    it's too generic but that's even more generic to me.
> Matt Stone: -1 To "verifiable attributes" also
> Manu Sporny:  We said we've been calling it credentials and we're
>    comfortable with it and these are the experts so we should call
>    it that.
> Manu Sporny:  We were expecting the group to push back so that's
>    good, we're in line.
> Brian Sletten: -1 To verifiable attributes and external names for
>    our topics of discussion :)
> Eric Korb:  So, the login systems in the blog post, are they
>    identity or credential systems?
> Manu Sporny:  Next topic will be talking about the capabilities
>    for the ecosystem and current proposal the CG is putting forward.
> Matt Stone: Employer: "show me your credentials" -- not "what are
>    verifiable attributes"
> Eric Korb:  In chart
> Manu Sporny:  Login systems in the blog post are viewed by the
>    browser manufacturers as credentialing systems, some call them
>    light-weight identity systems. I think the credentials CG is the
>    only standards-related group that has a glossary and has gone
>    through the technical differences of specific systems on the Web
>    like persona, etc. and distinguished them from Mozilla Open
>    Badges and other credentialing systems, etc. In the blog post we
>    talk about anything that could be considered an
>    identity/credentialing system in order to case a pretty wide net
>    to catch things people might often bring up. For example, we're
>    talking about credentials and people might say "Oh that sounds
>    like Oauth" and we put that tech in the post even if that
>    technology isn't a good fit for the depth of the problem and what
>    we're trying to get to.
>
> Topic: Credentialing Capabilities and Current Proposal
>
> Manu Sporny:  We just want to make sure we address common things
>    that are brought up even if they don't fit.
> John Tibbetts:  If we walk down the capability list and then say
>    a sentence or phrase for how our proposal addresses the issue.
> John Tibbetts:  That would be good.
> Matt Stone:  I'd like to know in addition to that, some level of
>    certainty that we know about this spec ... is it well understood
>    or do we have open issues that need to be solved, etc.
> Manu Sporny:  So I'll do "What is our solution, how does it rate
>    on the scale, and how sure are we/what tweaks need to be made
>    with our solution?"
> Manu Sporny:  The goals are meant to be fairly high-level, they
>    are from our vision statement.
> Manu Sporny:  The distinction that we're making is that ... that
>    people have asked. ... what's the difference between a "goal" and
>    a "capability" and a "feature".
> Manu Sporny:  Capabilities are things that the system should do.
>    When you're talking about a credentialing ecosystem, it should be
>    able to do these things, issue, store, manage credentials, etc.
> Manu Sporny:  Features are not capabilities, it is just a talking
>    point around a piece of software. It's a thing a software product
>    has. Marketing folks can talk about those features. Today we're
>    just going over the capabilities. The things we want a
>    credentialing ecosystem to have. Keep in mind that this list may
>    not be complete and may need to be refined.
> Manu Sporny:  As we go over the capabilities we'll talk through
>    them, refine them, and they'll eventually find their way into a
>    capabilities document.
> Manu Sporny:  "Extensible Data Model" -- this has to do with
>    choosing a way of modeling the data that will allow arbitrary
>    statements to be made.
> Manu Sporny:  This is a fundamental aspect of the W3C's Linked
>    Data/Semantic Web movement. There are open world and closed world
>    systems. The Web is an open world system; anyone can say anything
>    about anyone else. The fundamental data model for doing that at
>    W3C is called the Resource Description Framework (RDF), very
>    flexible, very will understood, under development for 15 years.
>    There are still fights over what the right solution for the Web
>    should be, academics vs. technical experts etc. XML tree model
>    vs. RDF vs. whatever.
> Manu Sporny:  We've tried to get the right practitioners into our
>    camp and we're using RDF via a JSON-LD syntax. We have a number
>    of reasons why we're using that.
> Manu Sporny:  Any organization or person should be able to make
>    any claims about any other org or person.
> Manu Sporny:  "Choice of Syntax" - So the data model is an
>    abstract thing, concepts related to other concepts, this person
>    knows this person who is in the organization and they know
>    another person who has a high school transcript that has this
>    piece of information, etc. It doesn't say how we express it to a
>    computer.
> Brendan Benshoof:  The core of the issue here seem less in the
>    representation and more in how statements translate to a real
>    state of affairs in the world.
> Manu Sporny:  So this is about syntax. Syntaxes come and go.
>    There's XML, then HTML, then JSON, then this then that. If we're
>    going to pick something that will be long lived then we should
>    decouple the syntax from the data model that expresses it. Today
>    we're going to pick JSON-LD to express the data model, but if it
>    goes out of favor by 2025, then the data model doesn't have to
>    change.
> Manu Sporny:  There's a subject, predicate, and object ... in the
>    data model. "Jane likes cookies". Every language works like this.
>    RDF works like this; it's a very flexible data model. We're
>    making an assumption that JSON-LD is great today but it may go
>    out of favor in 10 years. We don't want our solution to fall
>    apart if the syntax goes out of favor. So we create this
>    separation to avoid that.
> Manu Sporny:  "Decentralized Vocabularies" - A vocabulary is a
>    language that you use to describe something. The language that is
>    important to a Pharmacist or Medical board, is very different
>    from the language someone that is issuing a plumber's license of
>    an electronic transcript speaks. The terminology that they use is
>    very different. We shouldn't require those industry vertical to
>    come to a central place to agree on the language. They should be
>    able to develop their own language independently and innovate in
>    parallel. It enables market verticals to be able to come up with
>    their own solutions and talk about their industry how they want
>    to and not worry about how Google or IETF or whomever wants to
>    talk about their industry.
> Manu Sporny:  So these vocabularies allow us to create this
>    architecture and then let the people who come up with the
>    credentials to decide the language that's important to them and
>    they don't have to coordinate with us. It may seem like it's
>    common sense, but if you look at, for example OpenID Connect
>    specs, it tells you exactly how you express X, Y, and Z. If
>    anyone in Finance wanted to start talking about insurance IDs,
>    KYC stuff, etc. they'd have to go to IETF and lobby them to have
>    it added to the vocabulary. The IETF should not be in control of
>    how the education, pharmaceutical, etc. verticals mark up their
>    vocabularies.
> John Tibbetts:  All clear to me.
> Brendan Benshoof: +1
> Eric Korb:  Keep going! great to hear you speak
> Nate Otto: +1 Decentralized vocabularies are great.
> Manu Sporny:  Apologies if this is a firehose of information, but
>    it's taken us 4+ to get through all of this and it may take time
>    to sink in if it's new.
> Matt Stone: +1 Decentralized vocabularies are essential
> Manu Sporny:  It was so easy for us to integrate and interoperate
>    with mozilla open badges stuff because we've taken this open
>    world approach.
> Manu Sporny:  This design approach is the reason for that.
> Manu Sporny:  Web-based PKI. This might be a bit harder to grasp
>    for people who aren't familiar with security. I'll try to
>    explain. Most PKI systems, like those developed in 80's, 90's.
>    They require an X.509 certificate, if you've seen the pad lock on
>    your browser, etc. you're using this infrastructure. In the
>    beginning this infrastructure this was very secure; it was
>    difficult to issue "root" certificates for issuing these for
>    websites. But now the number of orgs issuing root certs has grown
>    to some 280 orgs/etc. The problem is that the US gov't can issue
>    certs for any org on the planet ... and so can China, India,
>    Pakistan. There are times when US and Chinese interests aren't
>    aligned (or whomever). So when you're inside China you get a
>    chinese certificate and they snoop all your traffic, etc. Nation
>    states do this all the time. The other problem with this system
>    is that there has to be a root of trust. In general, your
>    organization has to depend on some other organization for who you
>    can trust. So you have to trust both China and the US to use your
>    web browser in some circumstances which leads to problems. What
>    we're setting up doesn't require you to have this big list of
>    certificates in the same way; you can be picker with who you
>    trust. When you get a credential in this system, there will be
>    multiple signatures on it; one from the recipient, one from the
>    issuer, possibly ones from endorsers. The traditional way this
>    worked was that the system that was verifying the signatures
>    needed to have all of the certificates for all of the
>    organizations out there on your system already.
> Manu Sporny:  And that meant that centralization was encouraged
>    so you just trusted some big players.
> Manu Sporny:  Here the playing field is more level where you can
>    decide who to trust. All of the information you need to verify
>    the credential is in the credential or linked to it via the Web.
>    You can have small players claim keys and use them. And the
>    infrastructure is much more scalable as a result.
> Matt Stone: I have a question on this topic
> Manu Sporny:  This is important for scalability and a lot of the
>    OpenID Connect and JOSE specs dont' have this stuff. You have to
>    do key management and you can't do it on the fly with the Web.
> Matt Stone:  If I'm a consumer, if I get a credential in, would I
>    see a list of signed by "company A, person B, endorser C" and
>    they might be any. And it's up to me to decide if I trust those
>    parties?
> Brendan Benshoof: +Q What are we doing to allow ease of use for
>    consumers interacting with the PKI?
> Manu Sporny:  Yes, in general. A credential consumer that
>    receives the credential can decide who they want to trust. They
>    can push the responsibility off to another organization if they
>    want to or do it themselves. As a person receiving a credential,
>    all of this is kind of hidden from you. It's all machine to
>    machine communication that leverages all of this.
> Matt Stone:  Let's say I'm a chief medical officer at a hospital
>    and I want to see that they are board certified. They send me a
>    certificate. It's signed by X, Y, and their medical school.
> Brendan Benshoof: +Q How are we connecting Public-keys to
>    identities on the issuer's end??
> Manu Sporny:  Yes. That's the idea. In the current technology
>    multiple signatures aren't implemented yet.
> Dave Longley:  Is the question about multiple signatures, or is
>    it about who signed the credentials? [scribe assist by Manu
>    Sporny]
> Dave Longley:  The technology would do the verification of the
>    signatures, and tell you whether or not the signatures are valid
>    and were signed. You can figure out as a user, who did the
>    signatures and who signed it. [scribe assist by Manu Sporny]
> Dave Longley:  You have a private part of the key, and a public
>    key and can push that out to the Web. [scribe assist by Manu
>    Sporny]
> Brendan Benshoof: This means a lot of companies/Industries who
>    previously did not employ security professionals in this context
>    will need to (or oursource)?
> Dave Longley:  This has a lot to do with it being a web-based
>    system. [scribe assist by Manu Sporny]
> Eric Korb:  Suggestion that we add - "multilingual" or does
>    JSON-LD do that natively?
> Manu Sporny:  In the system that is being proposed here is more
>    flexible than the existing system and it allows you to do adhoc
>    verification.
> Manu Sporny:  Yes, JSON-LD does multilingual capability. The data
>    model is multilingual.
> Manu Sporny:  You can express the name of a credential in every
>    language that has a BCP47 code in the credential itself.
> Brendan Benshoof: +1 Multilingual (can we handle non-unicode
>    character encodings?)
> Manu Sporny:  The credential can be viewed by someone in Japan or
>    France in their native language; same credential.
> Nate Otto: That's a great capability.
> Matt Stone: Is multilingual an attribute of RDF of JSON-LD or
>    both?
> Matt Stone: +1 On multilingual
> Manu Sporny:  "Choice of Storage" -- has to do with letting you
>    store your credential wherever you deep fit. At Google, Facebook,
>    a home server running at your house, in your watch, the recipient
>    controls it and no org can stop them from moving them around. It
>    has a strong analogy with phone number portability.
> Nate Otto: Thanks, Manu
> Matt Stone:  "Both" ... specifically, multilingual is an
>    attribute of the RDF data model and JSON-LD uses the RDF data
>    model.
> Eric Korb:  +1 Manu overview
> Eric Korb:  Just need link to use case docs
> Nate Otto: See you all next week.
>
>
>
>
>
Received on Thursday, 20 August 2015 03:48:38 UTC

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