- From: <msporny@digitalbazaar.com>
- Date: Tue, 19 May 2015 12:54:36 -0400
- 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