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. ✪
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"} ✪
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: 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: 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. ✪
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. ✪
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. ✪
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.
… 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.