Verifiable Claims Telecon Minutes for 2016-01-28

Thanks to Dave Longley for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:

http://w3c.github.io/vctf/meetings/2016-01-28/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
Verifiable Claims Telecon Minutes for 2016-01-28

Agenda:
  https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Jan/0063.html
Topics:
  1. Problem Statement
  2. Stakeholders and Benefits
  3. SAML, Oauth, OpenID Connect, and JOSE
  4. Important Work Items
  5. Best Location for Standards Work
Organizer:
  Manu Sporny
Scribe:
  Dave Longley
Present:
  Dave Longley, Manu Sporny, Christopher Allen, David I. Lehn
Audio:
  http://w3c.github.io/vctf/meetings/2016-01-28/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Thank you joining us, Christopher. We're really 
  looking forward to getting your input on this VCTF work.
Manu Sporny:  Just to be clear we are minuting the call and 
  recording the audio.
Christopher Allen:  You have my permission.
Manu Sporny:  Let's start with a quick introduction -- we'll be 
  sharing this with multiple groups at W3C. Background and self, 
  etc.
Christopher Allen:  I've been involved with online communities 
  since the early 80's. I was one CompuServe, head of the computer 
  international consulting association ... consulting board on 
  there, I had hosted a number of BBSes, I published the first BBS 
  for the Mac and the first Mac interface for a online community.
Christopher Allen:  I was also involved with early pre-internet 
  methodology for transmitting information including [missed] which 
  is like news today but it's a p2p protocol. So we can talk about 
  how we did that back in the 80s, it's not new. In the late 80s I 
  was involved in [missed] involving the technological consensus 
  with database architectures and such and the human problem and 
  the core of what I wanted to work on for the next 25 years. I 
  came out with my first product and people didn't trust it so I 
  entered into crypto. I was involved groundfloor with RSA and its 
  algorithm and involved in its privacy efforts and [variety of 
  crypto tools] in the early 90s. That ultimately set the stage for 
  writing the reference implementation for SSL and then later 
  leading the standards effort for TLS 1.0 at the IETF.
Christopher Allen:  I was the editor along with Tim Dierks for 
  the standard and ran the online communities, mailing list, for 
  all practical purposes I was the defacto director of that working 
  group and we published version 1.0 of the standard in '97 and 
  today it's the most widely deployed security standard, [stats on 
  business]. Early architecture decisions we made proved to be 
  solid like perfect forward secrecy which was something that was 
  in the spec early on, it's only been implemented in the last 
  couple years. Not only used to secure the Web it's used to secure 
  other standards ... the ports I registered for doing SSL email 
  later TLS with email, Google reported last year 60% of all 
  outgoing email was secured by TLS and 50% incoming. Which is in 
  great excess of anything secured by SMIME or SFTP anything.
Christopher Allen:  In the last 10 years I've been an Angel 
  investor, involved in various online communities, in particular 
  in the mobile community. In the crypto field I did some work at 
  Certicom and did smart signatures and smart contracts but it was 
  too early, in the last few years I've been bringing those skills 
  back to secure android platform and most recently I've been doing 
  stuff in the blockchain with secure engines of trust in the last 
  yera, including teaching in university and doing consulting for 
  big and small. I've been working on OASIS standards to help XDI 
  move to blockchain.
Manu Sporny:  Awesome, that was a fantastic intro to you and 
  that's why we're so interested in hearing from you. We think 
  you're uniquely qualified to talk to -- about this problem space, 
  if it should be solved, how you'd solve it, etc.

Topic: Problem Statement

Manu Sporny:  What we're trying to do during this call is get 
  your thoughts about what we've written so far, user-centric vs. 
  service-centric, is there a problem to be solved, where should 
  the work be done, etc.
Manu Sporny: http://w3c.github.io/vctf/#problem
Manu Sporny: http://w3c.github.io/vctf/#design-approaches
Manu Sporny:  What we're trying to do is ... the main gist of the 
  way we're stating the problem here is that we're talking about 
  user-centric design. We're asserting there is no widely 
  user-centric standard for expressing verifiable claims, via the 
  Web and there's a desire to create such an ecosystem. We've tried 
  to define was user-centric means through talking about what some 
  of the design ramifications are. For example ...
Manu Sporny:  A service-centric system would be like facebook, 
  twitter, etc.
Christopher Allen:  Right, I'm very familiar with this movement, 
  as far as calling it user-centric was really pushed in the late 
  90s early 00s, augmenting the social network, the early thing ... 
  I've been part of the IIW community pretty much from the 
  beginning. The core of the ... problem, my alignment is with it 
  being about user-centric. It's been co-opted a little bit, but 
  I've been moving increasing into "self-sovereign" as the 
  key-phrase for this. Which is a little distinct from 
  user-centric. But clearly the same territory. I think ti's 
  important for a variety of reason. There's an innate power 
  imbalance in our society where individual power severely hampered 
  by the financial power and the legal authority of other parties. 
  Going back to the US constitution, how do you enable the 
  individual to balance that power around authorities.
Christopher Allen:  The natural power of aggregation of financial 
  authority, etc. we need forms of everything from the class action 
  lawsuit, etc. to overcome these kinds of natural aggregation and 
  network effects that happen in system.s
Christopher Allen:  We have to balance those natural powers with 
  powers that are for the user. That's where the self-sovereign is 
  a bit stronger and why I value that myself. Clearly, the world in 
  the last few years has been going ...
Christopher Allen:  We moved to centralized structures and we had 
  problems there and then out to decentralized and we had problems 
  there and then back to centralized and we're in the middle of a 
  centralized surge. Facebook, etc. Governmental powers wanting to 
  do things. I'm not a libertarian, I don't consider myself a 
  cryptoanarchist or anything, but I do believe in balance.
Christopher Allen:  That clearly is part of my motivation with 
  being involved in these decentralized techs that are finally 
  possible today. They haven't won. Banks, etc. are looking at this 
  as something they need to investigate. At this point there is no 
  proven example there.
Christopher Allen:  Walking through this, user-centric is the 
  first thing that I do, I am also very ... I think the space of 
  verifiable claims and attestations is a very important sweet 
  spot. Interop is very powerful. We've talked about 
  service-centric architectures mean that people who lose their 
  facebook relationship for whatever reason lose years of identity 
  and reputation and history with their peers.
Christopher Allen:  If you go by the individual definition of 
  social network individuals own their own social network, it 
  shouldn't be owned by a service. Lock in and fragility or the 
  opposite of it like resilience is important. Standards that cut 
  across industries, clearly, we have a lot of issues in the 
  area... I'm a big fan of privacy I write a lot about it but if 
  you look at a lot of things and how they are legislated like 
  HIPAA, they enforce a man in the middle. Which is the antithesis 
  of what cryptographers want to avoid but it's mandated by the 
  legislation. That has to do with the centrality of things again.
Christopher Allen:  Maybe they'll come up a little later in this 
  discussion, but I also want to look at things from a crypto 
  perspective and in order to prevent things like correlation, to 
  allow for certain kinds of privacy things mandated in the EU or 
  .... you can't do some of these without designing from a 
  self-sovereign perspective from the bottom. It *has* to be done 
  that way from a crypto perspective, I can't see how you can do it 
  the other way. You can have wonderful policies about how all of 
  this can work what can be shared and you can enforce them by 
  policy and then have things like "more Jews died in Holland in 
  WWII as a percentage of population vs. Germany" because policy 
  respected them but then things changed. So just because policy 
  works today doesn't mean it won't fail in the future. Building 
  things on human rights privacy is good but policy is based on 
  economic rights sometimes. The European style rights privacy 
  can't be solved by a service centric perspective, at least I 
  don't know how to do it, it can only be solved from a 
  user-centric perspective. 30+ years working in this community.
Manu Sporny:  Do you think we're in the right ballpark then ... 
  with our assertions about user-centric systems. If we were to do 
  one thing that would be creating this self-sovereign approach for 
  verifiable claims would that be a worthwhile endeavor?
Christopher Allen:  Yes. The only thing missing seems to be 
  policy and maybe more crypto.
Manu Sporny:  In way way do you feel it's missing? We point out 
  this needs to involve crypto, it's not a policy based solution 
  we're searching for it's a crypto-based solution?
Christopher Allen:  Yeah, and I dont' see that in the problem 
  statement.
Christopher Allen:  Nothing talks about that enough.
Manu Sporny:  Ok, I think that's just fundamental assumption 
  we're making but we should point out that that's how we intend to 
  address some of that in the problem statement. We were asked not 
  to propose solutions but to just identify the problem -- and let 
  the solutions come out in the actual work later.
Christopher Allen:  You're not mentioning it at all and you will 
  have to be diving into it. Even if you don't talk about it ... 
  maybe they are more principles, a couple of principles are 
  necessary to say, we've already talked about self-sovereign, but 
  maybe add to that something along the lines of minimum-disclosure 
  required to interact. Which might include methods like [missed]. 
  We don't know .. it's a hard problem space, we want to encourage 
  minimum exposure but we want to enable business interactions and 
  cooperation. So what is the minimum necessary to do so and not go 
  beyond it. Today it's all or none.
Manu Sporny:  We will try to work that in. Where should that go?
Christopher Allen:  Maybe as a "principles" type of thing.
Manu Sporny:  Any other concerns over the problem statmeent?
Christopher Allen:  Nope.
Christopher Allen:  Again another principle is the [missed]
Manu Sporny: The area of correlation
Christopher Allen:  The area of correlation.
Manu Sporny:  So I feel like we've covered user vs. service 
  centric design. User-centric being a better way to address the 
  problem.
Manu Sporny:  That's a fair statement?
Christopher Allen:  Yes, there are things in user-centric design 
  that make it harder for large orgs to do certain things but they 
  have more money and power, and I consider that an acceptable 
  balance.

Topic: Stakeholders and Benefits

Manu Sporny: http://w3c.github.io/vctf/#benefits
Christopher Allen:  I can live with this, every time I hit 
  "consumers" I understand you're trying to handle the naming here 
  ... whenever I hit "consumers" I keep wishing it was another 
  word.
Manu Sporny:  Do you understand what the term refers to? 
  Consumers of credentials, walmart, target, whatever.
Christopher Allen:  Absolutely.
Manu Sporny:  Let's go through the ecosystem and hear your 
  thoughts on it. Issuers issue credentials, holders receive them 
  put them in a digital wallet on their phone in the cloud, 
  wherever, they pick where they want to store it.
Christopher Allen:  Issuers is great, definition is solid. The 
  only thing obviously missing is that if we talk about human 
  trust, when it manifests itself in an enterprise there is a lot 
  of p2p trust ... I have a relationship with Joe at the powerbar 
  company because we've been doing business for a long time 
  together and he's his org have impressed me.
Christopher Allen:  There's a little "only these big issuers" 
  whereas I'm interested in the former CTO of PGP being able to 
  issue a statement about working with me in the standards industry 
  vs. verisign ... google almost banned them in Chrome because they 
  were miss handled ... which is a better credential?
Manu Sporny:  Right.
Manu Sporny:  We want to enable individuals to self-assert and 
  for orgs as well, it's not any harder. Want to cover all of it.
Christopher Allen:  What we've heard from Brad Hill is that he 
  doesn't see how that ecosystem could scale with that sort of 
  trust where trust is at the peer-level and it would fall under 
  its own weight.
Christopher Allen:  It does have to be constrained by recipes 
  more than it is by the size. If you look at PGP, trusting is 
  often over-interpreted, but fundamentally, do I believe that the 
  party at the other end has properly generated a public+private 
  keypair. That's all it really means. The problem is ... that's 
  not what it really says and it's not precise enough. If the 
  recipe could be what it really is instead of a broader 
  interpretation of what it actually means that would be much 
  better. All of these things that got interpreted into what a PGP 
  credential meant ... that's when it breaks. Having some good 
  recipes that are very precise as to their nomenclature and the 
  rules for that ... that can be done and can scale. Allowing 
  anyone to make a weird, reputation claim in a not-well reputation 
  claim in a weird area that's madness and there's no way to scale 
  that.
Manu Sporny:  One person said that one person said that what 
  we're looking at are islands of interoperability here (David 
  Chadwick).
Manu Sporny:  Orgs like in the education industry could have 
  their own vocab, etc.
Christopher Allen:  There's a fifth category, that's all over the 
  place in the real world. The accreditation ... I don't get 
  diploma from that body but it affects my degree. And having a 
  recipe for multiple bodies is better... that's a "recipe" that 
  you have these types of things. Having a fifth pipe where people 
  are creating these types of recipes are important, a good thing. 
  A recipe for US healthcare and things because of HIPAA and those 
  are different from EU things.
Manu Sporny:  With these four players in the ecosystem -- and 
  those other mechanisms that you just described, does the 
  ecosystem make sense to you?
Manu Sporny:  Where there can be many of each of these actors in 
  the ecosystem?
Christopher Allen:  Yes. With the thing ... the old word was 
  Relying Party for consumers, I agree "consumers" is better than 
  "relying party" but I'm uncomfortable with it. When you're trying 
  to communicate ... it crosses into the people side of the 
  equation. Are they followers, clientèle, or what.
Manu Sporny:  We'll mark that and take it back to the group to 
  look at a better name.
Christopher Allen:  I also appreciate the difference between an 
  issuer and a curator. I wrote a lot about ratings systems in my 
  blog and on collective choice... including in one of our own 
  ratings systems we got demonstrably better ratings [missed]. If 
  you look at that tech there's a big difference between a rating 
  and a ranking. Issuers are in the same space as rating and 
  ranking requires a lot more and that's where your curators are. 
  They have a very different role in saying "someone's credit 
  rating is greater than that of someone else's" as opposed to 
  "this person has great credit with VISA, their card has already 
  been paid on top." That's a different thing from a curation of a 
  lot of different ratings together. I think that's important and 
  curators may ... because of their power and because in order to 
  do some of their stuff they have to correlate things they may 
  have to have stricter requirements in many ways than issuers.
Manu Sporny:  One of things we talk about when we talk about 
  curators ... there are of course some tech proposals on the 
  table, and one says the curator should not be able to track where 
  you're using your credentials (from the consumers), if it can 
  figure that out then it can build a very strong profile of your 
  behavior and what you're doing and we're senstive to that and 
  trying to build that into the protocol.
Christopher Allen:  That's also where the power is and to a 
  certain extent the money. If you look at this from "who benefits 
  from it", the curators and consumers are benefitting the most I 
  think. In many ways, issuers are customers ... to a certain 
  extent, serving the community but also users, they can charge a 
  user for an ID, which is very different from a curator who can 
  force someone to do something.

Topic: SAML, Oauth, OpenID Connect, and JOSE

Manu Sporny:  Agreed. Switching gears ... technologies that can 
  achieve this kind of ecosystem and address the problem statement. 
  If you were trying to build something to achieve and create this 
  ecosystem... some people are saying the tech already exist and 
  just use SAML, OAuth, OpenID Connect, etc. Do you feel those 
  techs can just be reused to solve this? Are there still some 
  fundamental techs that aren't quite there?
Christopher Allen:  I've also been playing around with those same 
  things ... I'm uncomfortable with those things on a variety of 
  different levels, some of which are objective and some that are 
  subjective. On the objective issue side of things, I think that 
  in order provide for non-correlatable identifiers and things of 
  that nature you're going to have to use more complex crypto than 
  what is RSA-based single-key based CA-based architectures are of 
  the JOSE stack. And, they have a relatively constrained format 
  that makes some of those things hard. Obviously, every standard 
  can adapt. That's where we get to the subjective. I just find the 
  JOSE stack to be cumbersome and not ... I just hate the fact that 
  in order to both encrypt and sign something you have to actually 
  put the base64 of the encrypted thing in with it because the JSON 
  isn't consistent in how it's represented. It doesn't even have 
  lists. It just feels ugly to me and that's a subjective thing in 
  many ways.
Manu Sporny:  So you don't think that the JOSE stack is suited 
  for an ecosystem like this?
Christopher Allen:  It's very inelegant, yes. I also feel that 
  ... I can't tell you ... can it be done? Can it be coerced, 
  probably, but then it will be even uglier.
Christopher Allen:  Part of the problem ... switching hats to the 
  cryptographer hat. This was an issue with TLS way back when. 
  Everybody had a different algorithm and hash and MAC mechanism, 
  etc. They all wanted them to be able to slide in and in different 
  ways and combos. But auditing that from a security point of view 
  was *incredibly* hard. And that's kind of how I feel about JOSE. 
  On one hand they have some weird constraints but on the other 
  areas where I *want* to be constrained, they are wild. I want to 
  have two or three things ... or a linear growth in options rather 
  than an exponential growth in options and that's where JOSE is 
  going.
Christopher Allen:  And the fact that we need it to do things 
  that it doesn't do now, it will only get worse. They don't do a 
  number of different choices, they do it all as options as woven 
  in and out from each other, very hard to audit.
Manu Sporny:  Do you see any technologies on the horizon that can 
  address this type of stuff?
Christopher Allen:  Part of the reason why I've tried to get 
  involved with the XDI standard is they are trying to address some 
  of this, I'm not as much of an expert in the graph technologies. 
  Historically graph tech have led to a lot of dead ends, but there 
  are some interesting things in that space to solve these types of 
  problems. I've liked what's been going on with JSON-LD and XDI 
  and the OASIS standard and I haven't quite seen the same coming 
  out of JOSE.
Manu Sporny:  Is that with the data model or the digital 
  signature side of things?
Christopher Allen:  With the digital signature side of things. 
  The area of null nodes ... whether or not you need to have all 
  the world's data in some kind of graph, cryptography has problems 
  with null nodes. When you don't know about something and you 
  don't want to force that nullness... is a real problem in 
  cryptography.
Manu Sporny:  Got it. Jumping to other technologies, OpenID 
  Connect/SAML, could you modify those to get an elegant 
  user-centric system with credentials/claims expressed via them?
Christopher Allen:  You *could* but the architecture tends to be 
  very client-server architecture where the server is the key 
  party. And that's just always going to make it difficult.
Manu Sporny:  Is the assertion that OpenID Connect/SAML aren't 
  self-sovereign, etc.?
Christopher Allen:  Well, they aren't. But how the different 
  pieces are connected together are very oriented towards the 
  server being persistent in ways that limit them. That doesn't 
  mean you can't ... it's a classic thing of it being rooted on 
  HTML. That's how some of these other things arose with issues 
  like requiring a server-centric approach to it.
Manu Sporny:  I think what you're asserting is that there's 
  something here with the problem statement and creating this 
  ecosystem would be beneficial and there's no clear tech for it 
  today.
Christopher Allen:  That's latter statement -- it's a lot harder 
  with the current tech. What will be most easily adapted to the 
  kinds of changes necessary. Limiting crypto suites ... is a 
  desirable approach, not only doing crypto on the server, ... 
  there's no reason why in TLS you don't theoretically have the 
  server send a credential at all, .... you can get just the same 
  kind of MiTM prevention by having a client send something. It's 
  just that in the 90s the servers were more powerful than the 
  client, so you tried to do all the crypto on the server. That's 
  not true anymore. My iphone has a cryptographic co-processor 
  inside it with a hardened area inside of it. Even IoT ... we're 
  recognizing that you need to have crypto at the leaves. We need 
  to design for that.

Topic: Important Work Items

Manu Sporny:  If this work were to start, particularly which 
  items are important to work on? And where should that happen? 
  Self-sovereign identifiers, protocols, etc. Where should those 
  happen? IETF, W3C? ... So what are the techs and where should 
  they be created?
Christopher Allen:  If you start off with self-sovereign ... we 
  have a wallet and a key-management problem.  That's very 
  important, I happen to be really biased towards hierarchical 
  trees of keys because they allows a user to have a key completely 
  offline that can't be stolen yet allows them to create other keys 
  and delegate and let them do other things. I can let my phone do 
  a bunch of things on my behalf, but if it's stolen I can create a 
  new subkey very easily. I feel like that it's a fundamental thing 
  to design that from the beginning to support that type of 
  functionality. There are other benefits you get, for instance, I 
  can give the company I'm renting my apartment from an identifier 
  -- and the company I'm getting the power from ... and give them 
  each a different identifier and maybe they can't correlate (maybe 
  a bad example because they both have my physical address). My 
  email provider doesn't need to know those things ... if those two 
  companies share information those two identifiers wouldn't let 
  them correlate and say "oh, this is the same party." That's a 
  good thing for hierarchical keys. One of things with ratings 
  systems in general ... a rating is only is good as the point at 
  which it was issued, so time is very important. The persistence 
  of a rating over time is important.
Christopher Allen:  That needs to be built in early on. 
  Verifiable proofs of existence in time ... something that was 
  valid 10 years ago may have changed today, but if it's been 
  continuous over that time and never revoked then it has more 
  authority than what was given out today by a new issuer.
Manu Sporny:  So some kind of ledger or blockchain based 
  mechanism or history preserving mechanism?
Christopher Allen:  I'm not absolutely sure it needs to be a 
  ledger because it has issues of correlation and so on, but it 
  does need to be provable in time.
Manu Sporny:  What about identifiers and formats these claims?
Manu Sporny:  Are those good work items?
Christopher Allen: 
  http://www.lifewithalacrity.com/2005/12/systems_for_col.html
Christopher Allen:  Absolutely. I see a number of good recipes 
  ... there are human issues on recipes. Writing a good 
  rating/ranking system, various other kinds of systems are hard 
  and we need some good use cases and recipes and really understand 
  the problem and one of the first use cases is badges. Maybe 
  simply that you've completed something. Something that is less 
  than a degree but more than ... you've opened a webpage. That 
  there's been some kind of proof that you've read the document and 
  understood it in some fashion is a really early recipe that I 
  think we can design from the human issue perspective and use that 
  to make new recipes and more complex things.
Manu Sporny:  Could you clarify what you mean by "recipe"?
Christopher Allen:  As an example, there are ... you talk about a 
  JSON object I give you that basically says that I have rated the 
  paper you wrote, the blog post you wrote on a scale of 1-5 as a 
  3. I can prove to you that that's problematic. 5 star ratings are 
  a bad design, we do them repeated because people have seen them 
  in the past and they are used to them, but they have a number of 
  serious flaws. First off, a lot of people think 3 is the middle. 
  Well, 2.5 is the middle. There is no 2.5 stars. Due to the nature 
  of how you ask the question people are more likely to rate things 
  positively or negatively. An amazon book rating of 4 stars is the 
  low average. That means that your fellow buyers ... less than 50 
  percentile is a 4 star book. That's not obvious. People see that 
  as "oh that must be a good book." 4.1 or 4.2 is an average rating 
  for an amazon book. These are human sides of reputation, rating, 
  credentials.
Christopher Allen: 
  https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/rebranding-web-of-trust.pdf
Christopher Allen:  People started doing parties together and 
  people felt obligated to sign other people's keys because they 
  were at the party with you not because you truly believed they 
  generated their key safely. A human factor got in the way. These 
  kinds of human issues are important in the design of what that 
  JSON object looks like.
Manu Sporny:  Is there a particular set of tech at trying to 
  address that problem?
Manu Sporny:  Or a set of design thinking around how you solve 
  the problem?
Christopher Allen:  More the latter, but that being said, 
  "schemas" are powerful.
Christopher Allen:  I think that's one of the things ... you have 
  to be careful because schemas can get in the way also, but that's 
  the thing that the Microformats people discovered if are 
  relatively consistent with something that meets the use cases you 
  don't need to be as precise as full-fledged RDF.
Christopher Allen:  The schema was somehow more important than 
  perfectly described RDF. Having some good schemas ... having a 
  good complete discussion about "we've thought carefully about 
  this" and there are human factors in reputation systems and UI 
  issues and so forth that need to be accounted for.
Manu Sporny:  I think the conclusion we've come to is that the 
  people who design those schemas should be very close to the 
  problem. If you're designing a schema for hospitals, the 
  hospital/community or the people building stuff for them should 
  figure out the schema and the human factors, it shouldn't be some 
  standardization body. The point being that you need to have 
  experts in a particular vertical to do a good job?
Christopher Allen:  Right. I agree with that with the caveat that 
  a standards body can basically say "These are some of the steps 
  and perils and pitfalls that you can fall into if you're not 
  careful and here's our advice."
Manu Sporny:  Like a best practice around creating schemas.
Christopher Allen:  Yeah!
Christopher Allen:  And demonstrating some of those areas that 
  can be done, some of the best practices, explain the behind the 
  scenes ... here is why we chose ... a badge is a low-hanging 
  fruit. I have a definition of a badge, why is it relevant, where 
  are their problems, how do we avoid those problems, etc.
Christopher Allen:  Good lessons for you when designing your 
  recipe.

Topic: Best Location for Standards Work

Manu Sporny:  We're out of time and we really appreciate you 
  staying a few extra minutes. Do you feel like W3C, IETF, OASIS, 
  etc can do this work?
Christopher Allen:  The whole standards area. .. I would say IETF 
  20 years ago but not today. It's not the same it was back then. I 
  personally found W3C a little harder for small companies to be 
  involved with. It's a little bit dominated by the big browser 
  vendors and companies where I'd like to see a little bit broader 
  industry ... non-computer industry backing in there, but they 
  aren't there.
Christopher Allen:  I only have limited exposure to OASIS, last 9 
  months or so. It at least enforces IP stuff and the minimums 
  there to make sure parties will be treated fairly. It's a little 
  too close to the metal there. They are doing interesting work in 
  crypto though. Technically it's not the IETF ... it's the IESG 
  that's doing more crypto stuff.
Manu Sporny:  Crypto forum research folks?
Christopher Allen:  Yes.
Manu Sporny:  Thank you so much for your time today.
Manu Sporny:  To be clear you think it's worthwhile to work on 
  this stuff.
Christopher Allen:  Yeah.
Manu Sporny:  Expressing verifiable claims and so on.
Christopher Allen:  Yes.
Manu Sporny:  Ok, thanks and have a great week, we'll CC you on 
  this!

Received on Thursday, 28 January 2016 22:50:21 UTC