<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Here are the notes I took yesterday. Please check that I listed
      all the attendees.<br>
    </p>
    <p>Attendees<br>
      Manolis Viennas<br>
      David Chadwick (notes)<br>
      Torsten Lodderstadt<br>
      Kristina Yasuda (Chair)<br>
      Judith Kahrer<br>
      Philipp Lehwalder<br>
      Nemaja Patrnogic<br>
      Jan Vereecken<br>
      Brian Campbell<br>
      Micheal Jones<br>
      Oliver Terbu<br>
      Pedro Felix<br>
      lukasz Jaromin<br>
      Juba Saadi<br>
      Javier Ruiz<br>
      John Bradley<br>
      Paul Bastian<br>
      George Fletcher<br>
      Daniel Fett<br>
      Tom Jones<br>
      Daniel Fett<br>
      Ben Piercey<br>
      Brian Campbell<br>
      Sébastien Bahloul <br>
    </p>
    <p>Manolis introduced himself, from Scytales.</p>
    <p>VCI PR#276 (Define claims display description and claims path
      query)<br>
      Daniel explained that this changes claim names into an object with
      a path and claim name. This caters for both nested claims and
      arrays of claims. An addition to support object types has also
      been requested. It should work for both X.509 and CBOR encoded
      claims. There is already an example for an ISO mdoc. Kristina said
      that using null is fine, but should the array have mixed integers
      and strings for values? Joseph said the alternative is to use
      strings everywhere, but this wont help to differentiate between a
      real integer and a real string. Pedro thinks using the same model
      for authz details and metadata might introduce difficulties for
      odd/edge cases. Also wouldn't it be better to have different
      object models for Authz details and metadata description that
      share the same path description rather than putting exclusions in
      one of the object models? Joseph said this should be an editorial
      change. John asked how does the issuer specify a policy for the
      wallet that constrains what it can display to untrusted verifiers?
      This does not seem to have been discussed anywhere. Torsten said
      that John's issue is about the issuer controlling what the wallet
      can display/transfer to verifiers, but this PR is about how the
      wallet displays to the user details of the issued credential. Paul
      said the authz details description should not be linked to claims
      description but only to claims path query. Kristina said this is
      an editorial issue.<br>
    </p>
    <p>Kristina has requested reviews on this PR from a large number of
      the WG attendees.<br>
      <br>
      VP Issue #112 (Opportunities to improve the credential
      query/request syntax)<br>
      Kristina introduced this issue and asked people to state why they
      do not like DIF PE.<br>
      Should we keep PEv2 or work on PEv3 or define our own query syntax
      or just have this as an extension point for any query language to
      be plugged in.<br>
      Mike stated that its complexity e.g. algebra can lead to interop
      problems.<br>
      Torsten stated that the VP protocol supports credentials in
      multiple formats, and PE allows the format to be stated first
      before the query is presented. Many people have implemented PE so
      dropping it can have large consequences.<br>
      John stated that a unified format independent query language is a
      strength of PE.<br>
      Brian supports the extensible model but Torsten says we have
      failed in interop if we make it an extension point.<br>
      <br>
    </p>
  </body>
</html>