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

Credentials CG Telecon Minutes for 2015-05-19

From: <msporny@digitalbazaar.com>
Date: Tue, 19 May 2015 12:54:36 -0400
Message-Id: <1432054476860.0.26374@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Gregg Kellogg and Manu Sporny for scribing this week! The minutes
for this week's Credentials CG telecon are now available:

http://opencreds.org/minutes/2015-05-19/

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-05-19

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2015May/0020.html
Topics:
  1. Introduction to Jordan Windsor
  2. Open Badges xsd:string issue
  3. WebAppSec Credential Management API
  4. Graph Normalization Test Suite
  5. Community Group Focus
Action Items:
  1. Gregg to split 2015 normalization out to separate repo on 
    json-ld.org.
Organizer:
  Manu Sporny
Scribe:
  Gregg Kellogg and Manu Sporny
Present:
  Gregg Kellogg, Manu Sporny, Nate Otto, Jordan Windsor, Dave 
  Longley, Brian Sletten, Richard Varn, Eric Korb, Kerri Lemoie, 
  Sunny Lee, David I. Lehn, Victoriano Giralt
Audio:
  http://opencreds.org/minutes/2015-05-19/audio.ogg

Gregg Kellogg is scribing.
Manu Sporny:  Webappsec update, graph normalization, Credentials 
  management API extension
  … Also, a small mod to the openbadges context via taaz

Topic: Introduction to Jordan Windsor

Nate Otto: Welcome, Jordan!
Jordan Windsor:  My name is Jordan Windsor - listening in, 
  interested in evolving technologies impact our business - 
  interested in Credentials on behalf of Lexus of Richmond. [scribe 
  assist by Manu Sporny]
Nate Otto: This is an open channel, and we're gald to have you.

Topic: Open Badges xsd:string issue

Manu Sporny is scribing.
Nate Otto: Demonstration of the xsd:string problem in the open 
  badges context: 
  http://json-ld.org/playground/#/gist/0d1ca2097f94cae690cf
Manu Sporny:  We detected an issue with the Open Badges context, 
  and the output suprized us. [scribe assist by Gregg Kellogg]
Nate Otto:  I’ve confirmed the behavior, but haven’t pushed out 
  an update yet. [scribe assist by Gregg Kellogg]
Dave Longley:  I can summarize the issue
Dave Longley:  When the new open badges context was first put 
  out, I believe you were adding, for certain term definitions - to 
  only apply to strings.
Dave Longley:  You were setting the type to an xsd:string - 
  unfortunately, the JSON-LD processing rules consider @type to be 
  completely opaque, so what that means is - in plain JSON strings 
  for your values, instead of JSON strings that have xsd:string 
  @type, the processor will see them as two differen things.
Dave Longley:  Processor won't see as JSON string - xsd types are 
  only interpreted by the toRDF and fromRDF algorithms in JSON-LD. 
  In effect, what happens is that if you have a context, and you 
  have "name" and you say it only applies to things w/ "xsd:string" 
  - if you have type xsd:string on it - compact using that context, 
  that term will not be detected. It'll use some other rule in your 
  context.
Dave Longley:  JSON strings don't map to that in 
  expansion/compaction rules. Automatic translation doesn't happen 
  - some items don't compact down. So, JSON-LD 1.0 - if you want a 
  term to be selected for values to be selected for JSON strings, 
  you can't restrict it to just strings.
Dave Longley:  However, that's ok - JSON-LD contexts aren't 
  supposed to be used for validation.
Dave Longley:  You can use JSON Schema for validation.
Nate Otto:  We were just putting it in there to provide as much 
  info as we could - here's what you should expect to find. 
Nate Otto:  I have a question on other types - is there any 
  useful information I can put in the context for the type of info 
  about their ID?
Dave Longley:  When you're creating term definitions in the 
  context they're definitions that a processor will use to take a 
  property and replace it w/ a term. JSON-LD processors see 
  properties come in w/ a value, if there is a match in the JSON-LD 
  context, it'll replace it w/ a shorter form of it.
Gregg Kellogg: Dlongley describes the use of context for 
  compaction, it has other roles when expanding.
Dave Longley:  Don't think of it as a way of providing hints for 
  people. If you want to restrict it by type, put the type in 
  there. That is a hard restriction, if the type doesn't exist in 
  the data, the term will not be selected. If you want things to 
  compact down, don't put the type in there unless the incoming 
  data has that type.
Nate Otto:  Will that property be selected with proper type 
  information?
Dave Longley:  If you have a term that's not restricted by type, 
  if that's the only term available, the property associated w/ the 
  term will be compacted, but the @value/@type will be the same 
  (but expanded), but the term will compact down.
Nate Otto:  Ok, will make changes in a bit and we'll put it into 
  production shortly.
Dave Longley: For example - "http://example.com/term": {"@value": 
  "foo", "@type": "bar"} - "term": {"@value": "foo", "@type": 
  "bar"}
Nate Otto: https://openbadgespec.org/v1/context.json Here's the 
  context for instance.
Gregg Kellogg:  I'll note that there is other information that 
  you can put in a document containing a JSON-LD context, not used 
  by JSON-LD processors, but many of the vocabularies I work on, 
  the context is published at the location of the vocabulary. An 
  RDFs definition of that vocabulary, it's entirely consistent to 
  have the body of that document have an RDFs definition. It's 
  completely unused by a JSON-LD processor, but is a good way to 
  document what your JSON-LD context is doing.
Gregg Kellogg:  Interesting, we're using some additional material 
  in our context just like you describe, but it's an open badges 
  specific addition of links to validation schema using JSON-schema 
  [scribe assist by Nate Otto]
Nate Otto:  We do have some links on structural validation in our 
  JSON-LD context documents in the future. We hope to integrate 
  that stuff in in the future.

Topic: WebAppSec Credential Management API

Dave Longley:  Manu and I were on the WebAppSec call yesterday, 
  where they were talking about Credential Management API progress. 
  We had a short discussion at end of that call.
Dave Longley:  Summary of what was discussed on the call: 
  https://lists.w3.org/Archives/Public/public-webappsec/2015May/0101.html
Dave Longley:  Essentially, there are a couple of concerns that 
  we have w/ the existing API and how it can be extended to support 
  Credentials CG credentials in the future.
Dave Longley:  The current API is supportive of "same-origin 
  credentials" - which are credentials generated for a specific 
  site and only work on one website.
Dave Longley:  They are operating on the basis that the 
  interaction that you go to a website, get a credential from that 
  website, and use the credential only on that website.
Dave Longley:  The Credentials CG credentials assume the scenario 
  where you get a credential from one website and need to use it on 
  a different website - these are "cross-origin credentials".
Dave Longley:  We have to make sure that the Credential 
  Management API will work with cross-origin credentials.
Dave Longley:  We need to make sure of 2 things, at least:
Dave Longley:  The first is that the credential can't be "who you 
  are" - it's that an identifier is associated with a set of 
  credentials.
Dave Longley:  The second is that you can go off to a remote 
  website to fetch your credential. Credential storage doesn't have 
  to just happen in your local browser. You have to be able to 
  store and retrieve credentials from other websites.
Dave Longley:  3Rd party storage/retrieval is important to use, 
  otherwise you end up locking your credentials into your browser.
Dave Longley:  You enter username/password that's easy to create 
  a credential from that - you can't easily re-create a drivers 
  license, or a corporate ID card.
Dave Longley:  We need to make sure we can use cross-origin 
  credentials.
Dave Longley:  We need to make sure that browser implementers can 
  integrate w/ our type of credentials.
Dave Longley:  We've signed up to formulating how credentials 
  would work w/ cross-origin credentials and the Credential 
  Management API.
Dave Longley:  We're going to sync up w/ them next week after 
  we've put our proposal forward.
Nate Otto:  It seems to me wrt. WebAppSec - they're thinking all 
  about authentication - the person is who they expect. That's an 
  important part of our credentials as well. We can't have someone 
  else presenting our credentials - but we have an idea of how to 
  do authorization to do more interesting things. 
Nate Otto:  Those credentials that I'm showing you authorize me 
  to do more interesting things w/ your system.
Nate Otto:  It seems like what they're doing just formalizes the 
  status quo - we're hoping for a broader feature - a service can 
  switch on the credentials you have.
Dave Longley:  Yes, that's exactly right. What we've found is 
  that the way we've modeled it - you can provide different 
  credentials to provide deeper authorization. It covers just about 
  every use case you could think of. The login case that they're 
  dealing w/ is just one tiny case.
Dave Longley:  That's really what login is.
Dave Longley:  They ask for a subset of information about you - 
  to prove information is true - to take a variety of actions.
Nate Otto:  They're really only looking at Credentials Management 
  API from a login point of view, has it been difficult convincing 
  them that the problem is broader than what they're focusing on 
  and that's constraining their solution?
Dave Longley:  We really haven't had enough time to go through 
  everything w/ them. We don't want to expand their scope, and 
  there is this W3C Process issue we're bumping up against. We 
  can't talk about too much outside of their Charter. We can only 
  talk about extensibility, not about what we're doing.
Manu Sporny:  That's one of the big unfortunate things of how 
  this is coming about. Maybe Eric or Melvin sent me an email 
  letting me know there is a new working group that has to do with 
  account selection at w3c [scribe assist by Nate Otto]
Manu Sporny:  That means there are 5 groups at W3c that are all 
  kinda-sorta working on the same thing, and it's looking like W3C 
  is not doing as good a job coordinating all these groups together 
  as they should be. We're trying to do that work and connect them 
  together so there isn't the disaster of 5 different APIs. [scribe 
  assist by Nate Otto]
Manu Sporny:  W3C process is written so that working groups 
  should not go outside their charter, so the only thing we can 
  discuss in the WebAppSec group, is this login thing, and because 
  that's their charter, they're looking at the solution in a 
  constrained way. Therefore, we can only be looking at the 
  extensibility part of their API. [scribe assist by Nate Otto]
Gregg Kellogg:  W3C "Activities" are coordinated by Activity 
  Leads. It seems like these groups span more than one activity, 
  but it seems there is some coordinating entity necessary for 
  this. [scribe assist by Nate Otto]
Gregg Kellogg:  Typically there are activities - W3C has activity 
  areas that cover broad sets of things that are interrelated. 
  There is an activity lead that is responsible for coordinating 
  this work. There seems like there is some coordinating entity 
  that's necessary - perhaps there are other areas that require 
  interactivity coordination.
Gregg Kellogg:  Has there been any discussion, or has there been 
  any insight into that process? [scribe assist by Nate Otto]
Manu Sporny:  The person in charge of coordination is overloaded, 
  so this has been lost. [scribe assist by Gregg Kellogg]
Gregg Kellogg: … Eg, the credential management API folks don’t 
  see the need to cover us, because of the narrow interpretation of 
  their charter.
Gregg Kellogg: … There’s fundamental disagemenet as to how much 
  overlap there is. Many feel that these should evolve separately, 
  and bring them together later.
Gregg Kellogg: … Our feeling is that this will lead to 4 
  different APIs that overlap, but will never be resolved.
Gregg Kellogg: … Conversations are ongoing. WebPayments IG will 
  make some recommendations to W3C; fundamentally, we just need to 
  get 3 key W3C people together to make this point.
Dave Longley:  Fundamentally, the work we're doing here 
  encompasses what the other groups are doing. They're focusing on 
  more narrow use cases that fit into the larger design that we 
  have for credentials on the Web. Hopefully we can teach people 
  that that's true.
Manu Sporny:  The other danger is that, eg, dlongley and I need 
  to go off and invent a credential management extension, and we’re 
  falling behind. This will make it difficult to stay up to date 
  across all these groups, and we’re likely to get run over by the 
  narrow focus of these groups. [scribe assist by Gregg Kellogg]
Gregg Kellogg: … In this iteration, it’s been a month, and 
  they’re waiting to go, but we’ve been swamped.
Gregg Kellogg: … It’s going to be difficult for us to respond to 
  respond to these issues.
Gregg Kellogg: … This take away from time necessary for 
  recruiting, summaries, and so forth.
Gregg Kellogg: … We need help on the other documents: use cases, 
  recruiting, architecture, etc. Otherwise, we won’t be ready when 
  W3CM asks us to start official work.
Nate Otto: Sunny, Kerri and I can do work on the Use Cases doc 
  this week.
Brian Sletten:  I can work on the use cases too, next week. 
  [scribe assist by Gregg Kellogg]
Manu Sporny:  We need to start recruiting this or next week. i’ll 
  send out about 75 emails to get the process going. [scribe assist 
  by Gregg Kellogg]
Gregg Kellogg: … We really need a document we can send out to new 
  members, so that people in this group can show it to recruit new 
  members.
Gregg Kellogg: … If you follow the request, they want a survey of 
  all previous systems to show why they don’t work. It will take a 
  long time to prepare such a response.

Topic: Graph Normalization Test Suite

Gregg Kellogg: https://github.com/ruby-rdf/rdf-normalize
Gregg Kellogg:  I started working on my own implementation of RDF 
  Graph Normalization
Gregg Kellogg:  A part of what I ran across - there are two 
  different normalization algorithms in use right now 2012 and 
  2015.
Manu Sporny:  We need graph normalization to digitally sign 
  credentials, so that people can verify and trust them.
Gregg Kellogg:  We'll probably need a separate repository that 
  focuses on normalization, which can then serve as the basis for a 
  normalization micro working group or whatever it might be. There 
  is precendence for this. There is a W3C group on github where 
  different WGs maintain repositories for issue management and 
  stuff like that.
Gregg Kellogg:  Gh-pages can serve as a web home for this stuff - 
  CSV on the Web group work like this. It was my thought that it's 
  time for us to separate out the normalize work at least into its 
  own repository so we can move it forward and get it prepared. 
  Because it is so specialized, it's not in the core expertise of 
  this particular group, having it as a separate repo allows the 
  conversation to develop on their own. Move it to some place else 
  moving foward.
Dave Longley:  I'm in favor of moving it over to its own 
  repository.
Manu Sporny:  Me too.
Gregg Kellogg:  Then I'll take the action to do that - we can do 
  that under the JSON-LD github organization.
Manu Sporny:  Yep, that location sounds great.

ACTION: Gregg to split 2015 normalization out to separate repo on 
  json-ld.org.

Gregg Kellogg:  Out of the 50+ tests, I pass all but 7 of them.
Nate Otto: Good work, gkellogg ! Independent implementations!
Gregg Kellogg:  We're close to 2 interoperable implementations. 
  It was pretty easy to implement, some of the nomenclature was 
  difficult to understand, we can correct it.
Gregg Kellogg:  It's much more straighforward than the 
  canonicalization algorithms used for graph isomorphism.
Dave Longley:  It looks like it's under 250 lines in Ruby.
Gregg Kellogg:  Yeah, it's pretty small, which is good.
Gregg Kellogg:  I think the algorithm descriptions are a bit too 
  low-level - something in between a mathematical proof and a 
  by-the-numbers implementation.
Dave Longley:  I agree.
Gregg Kellogg:  Having something described that can be 
  independently implemented and come this close to interop is key. 
  So, that's good.
Gregg Kellogg: 
  http://aidanhogan.com/docs/skolems_blank_nodes_www.pdf
Gregg Kellogg:  We will want to clean it up a bit, but given that 
  there is no WG whose mission to push it forward doesn't exist yet 
  - but interest is increasing due to the new Skolem paper.
Manu Sporny:  Huge kudos to Dave Longley for figuring this out 
  years before this paper came out.
Gregg Kellogg:  I think that this work was so closely percieved 
  as being associated w/ JSON-LD that is why it wasn't mentioned, 
  which was false - it had a great deal to do w/ general RDF stuff. 
  We need to get it into a separate WG, to get others invovled.

Topic: Community Group Focus

Gregg Kellogg is scribing.
Manu Sporny:  The first priority is to start recruiting. this 
  will take up to 3 months to achieve.
  … 1) We’re trying to convince W3CM that this is worth doing. 2) 
  to get new members into W3C. 3) we need to bring internal and 
  external organizations up to speed so they’re comfortable to 
  start a WG, instead of going into background research mode.
  … The degenerate case we don’t want to fall into is to create 
  an IG to discuss what should be done. That’s why we’ve been 
  operating for the last year.
  … I’ll get W3C Membership on board. We can start recruiting 
  using the use cases and executive summary as is.
  … The second stange will be to go after large orgs, which 
  aren’t currenlty members.. What we don’t have is a high-level 
  summary of credentials and the standards process.
  ... We need volunteers to create these documents, which need to 
  be there before this can be done.
  … Once we have a questionare filled out, we need to convince 
  them that our plan will work. We have Badge Aliance, vocabuarly, 
  and identity credentials specification.
  … If we do that as a first step, we’re on our way to making 
  this the default way that credentials are stored and exchanged on 
  the web.
Richard Varn:  Credentials need a standard; that’s a statement of 
  advocacy.
  … 2) W3C is the right place to develop this standard
  … 3) The credentials group is the right way to do this.
  … We also need existing and new W3C members to staff and 
  populate to make this work.
Eric Korb: I lost connection to voip
  … If we have a document, or section for each of these points, 
  this will help.
  … We have something that we’ve used, and perhaps we can submit 
  something that will help.
Manu Sporny:  Richard will poke around to get core materials. The 
  structure you outlined is great, we’ll work with that with input 
  from ETS. Hopefully we can get it out next week.
Richard Varn:  Of course, the W3C should have documents for much 
  of this, so it may be more assembly than authorship.
  … If you have some existing source documents, point me to them 
  and I’ll use those to create a framework.
Manu Sporny:  We also need to make another pass on the use cases 
  document.
  … What comes after use cases is requirements and basic 
  capabilities, but there’s time to do that. A new group won’t be 
  created until late September.
Kerri Lemoie: Will do. :)
Received on Tuesday, 19 May 2015 16:55:00 UTC

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