W3C home > Mailing lists > Public > public-credentials@w3.org > June 2021

[MINUTES] W3C Verifiable Credentials HTTP API Call - 2021-06-01 12pm ET

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Tue, 01 Jun 2021 16:47:48 -0700 (PDT)
Message-ID: <60b6c724.1c69fb81.a5576.4ec0@mx.google.com>
Thanks to aaron_coburn for scribing this week! The minutes
for this week's Verifiable Credentials HTTP API telecon are now available:

https://w3c-ccg.github.io/meetings/2021-06-01-vchttpapi 

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

----------------------------------------------------------------
Verifiable Credentials HTTP API Telecon Minutes for 2021-06-01

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2021Jun/0000.html
Topics:
  1. Use Cases Update
  2. Authorization Part Deux
Organizer:
  Manu Sporny
Scribe:
  aaron_coburn
Present:
  Manu Sporny, Mike Varley, Markus Sabadello, Eric Schuh, Aaron 
  Coburn, Henry Story, Adrian Gropper, Andreas Freund, Sanuja, 
  Diwala, Brent Shambauh, Juan Caballero, Ted Thibodeau, Anil John, 
  Orie Steele, David Ward
Audio:
  https://w3c-ccg.github.io/meetings/2021-06-01/audio.ogg

aaron_coburn is scribing.
Manu Sporny:  Welcome to the weekly HTTP API call. This is the 
  new time for the call
  ... today's agenda: continuation of authZ discussion
  ... possibly some preliminary descisions if there is consensus
<tallted> confirming -- delete repeating Thursday 3pm ET, 
  effective this week?
  ... are there any updates to the agenda?

Topic: Use Cases Update

Eric Schuh:  Update on use cases document
  ... the new date is june 14, two weeks from today
Eric Schuh: Deadline for new use cases: June 15
<tallted> s/june 14/june 15/
  ... more use cases have been added
  ... many are single-sentence, so we are looking forward to 
  expanding those
Juan Caballero:  We have been leaving comments on some longer use 
  cases
  ... with clarifying questions
Manu Sporny:  Please add more if you have interesting use cases
  ... any other status updates?
Juan Caballero:  One of Mike's use case: he already answered a 
  clarifying question; it might be good to walk through one of his 
  use cases at the end (Trust Agent)
  ... whether the trust agent is an api detail
Manu Sporny:  Any other use cases for the agenda?

Topic: Authorization Part Deux

  ... if not we will get started with Authorization
Mike Varley: +1 To tackle the Trust Agent use case if there is 
  time and determine if it is in scope.
  ... to summarize last call: what is in scope / out of scope
  ... don't put future authZ schemes out of scope (GNAP/ZCAP/etc)
  ... one suggestion to put such things as GNAP out of scope 
  initially
  ... one suggestion to focus on OAuth2
  ... today: see if we can get to a proposal
  ... is this summary accurate?
Adrian Gropper:  OAuth2 is about authorization but not delegation
  ... how do we determine how delegation is in scope/out of scope
  ... esp. w/r/t self-soverign
  ... do we need to include UMA?
Mike Varley:  Not about delegation
  ... clarify: is this for system-to-system (e.g. 
  client_credentials)
  ... or both?
  ... or personal interaction w.r.t consent?
Manu Sporny:  Several layers to this. Most focus has been on 
  client_credentials
  ... for general access control (simple case) OAuth2 makes sense
  ... for those endpoints that could be abused w/o an authZ layer
  ... or: for those endpoints (such as presentation) one doesn't 
  need authorization
  ... those very much in scope
  ... delegation is trickier: what are you delegating?
  ... we need a concrete use case
  .... how does one doe that w/ OAuth2
  ... how does one do that with other mechanisms
Andreas: pull vs. push use case
Manu Sporny:  Is it assumed that authZ is required to do that?
Andreas: assumption is that authZ is needed
  ... e.g. I have a presentation to make
  ... here is domain/endpoint/challenge
Manu Sporny:  There is a "start workflow" use case like this
  ... is there authZ required on this endpoint, or do you just 
  start
Andreas: is there something out of band in the communication?
Henry Story: I was wondering how the Authorization fits with the 
  Solid Authorization use cases we put together 
  https://solid.github.io/authorization-panel/authorization-ucr/#uc-privacy
<andreas_freund> @aaron ... there is the assumption of out of 
  band communication to establish a trust relationship between 
  requester and target systems
Manu Sporny:  Delegation -- what use case affects the HTTP API?
<andreas_freund> that is what i meant
Thanks @andreas
<bblfish> ok, changed browser
Adrian Gropper:  Receive direct from the issuer or if the message 
  needs to be encrypted so the holder cannot read the data
  ... streaming of credentials -- could be discarded by the 
  holder
  ... cases where revocation mechanisms are not available
Henry Story:  Solid authorization use cases -- these could be 
  helpful
  ... possibly the terminology is different
Manu Sporny:  Could you send your message to the CCG mailing list
  ... could you provide a summary now?
Henry Story:  Read access / write access to a resource
  ... use cases for credentials (over a certain age)
  ... how a client would know what credentials it has to give
  ... server doesn't want to leak too much information
Manu Sporny:  Some folks see the HTTP API is an ecosystem API 
  when in fact it is more focused on issuing VCs
  ... the UCs provided by Henry might be more appropriate for 
  confidential wallets
  ... looking at the endpoints themselves, we need to ask whether 
  certain endpoints need authZ or delegation
  ... seems that @adrian's UCs relate to the content of the data
Adrian Gropper:  The VC is a resource
  ... what is manu asking? There is just the endpoint that will 
  accept/produce the VC.
Manu Sporny:  We need to be more specific about what these 
  endpoints do if we want to talk about authZ
  ... otherwise we'll keep going around in circles
  ... one possiblity: we talk about each endpoint and discuss 
  what the endpoitn needs
Andreas: need to distinguish b/t authZ of the endpoint and authZ 
  of the resource
  ... can the target system be called by the requestor system?
  ... I have SAP (A) on one side and Oracle (A)
  ... if oracle (B) doesn't know that SAP (B) isn't delegated by 
  SAP (A), it would reject that request
  ... but we would want a delegation model that would allow these 
  sorts of interactions
Adrian Gropper:  We have HTTP in the specification name
  ... one brings a token that allows one to call that resource
  ... what is the issue about multiple endpoints? HTTP says it 
  all
Andreas: the different endpoints do different things: some are 
  public some are not
Adrian Gropper:  Does the resource owner have ability to delegate 
  to another entity
  ... difference b/t oauth2 and uma
Andreas: e.g. SAP (A) delegates to SAP (B)
Andreas: system a requests a resource (a presentation)
Manu Sporny:  I think the kind of delegation adrian is talking 
  about is out of scope
  ... by "resource", the language adrian is using could be 
  interpreted in several ways
  ... if you're reasoning about the VC, that is out of scope
Adrian Gropper:  Agreed
Manu Sporny:  Can you hit the endpoint or not
  ... if so, you can issue anything
  ... unless we have a very fine-grained authZ framework
  ... two levels: can we do the simple stuff (OAuth2)
  ... e.g. direct system-to-system calls
  ... after that, what kind of delegation do we want to support
  ... keep the complex authZ mechanisms in mind
  ... but keep the simple use cases front and center
Adrian Gropper:  OAuth uses string to determine scope
  ... in confidential storage WG: does the subject have the right 
  to delegate access
  ... not whether the subject has the ability to read/write
  ... sees this as a human rights issue
Manu Sporny:  I will try to pose the issue differently
  ... I don't understand the human rights issue
  ... can we talk about this as a priorities thing?
  ... start with the simple tasks
  ... move the complex items to later (while keeping them in 
  mind)
  ... would there be any objections to prioritizing the simple 
  stuff
<adrian_gropper> Yes - I would object.
Adrian Gropper:  Object on the grounds of 10 years of experience 
  of the disaster caused by oauth in the health care industry
  ... colleagues have all moved from OAuth to GNAP
  ... reduced to login with Google/FB
  ... OAuth needs to go away
Orie Steele: -1 To moving from an establshed standard to a DRAFT 
  that is WIP.
  ... serves B2B use cases
  ... doesn't help self-soveign protocols
Manu Sporny:  Anyone to speak to OAuth2 use cases
Ted Thibodeau:  OAuth is not reduced to those two providers
  ... we have an auth layer that allows dozens of providers to be 
  used
  ... argument is spurious
  ... many have chosen to leave OAuth, but the reasoning is 
  flawed
Orie Steele:  As a standard, OAuth has been adopted by a large 
  number of providers
  ... it's not a draft or work item
  ... it has flaws
<bblfish> On the whole I am on Adrian's side, I don't think it 
  OAuth for Solid is really the right tool for example.
  ... many of the design decisions have caused trouble for OAuth
  ... but it has also stood up over time
  ... there isn't a better solution today for OAuth
  ... there are social issues ("nascar problem") but that doesn't 
  mean that OAuth isn't a foundation worth building on
  ... starting with OAuth could, in fact, help this effort to 
  take off
  ... it has been very difficult to replace OAuth
Manu Sporny:  I think we're conflating things
<orie> sure OIDC is built on OAuth....
  ... when we say OAuth2 means "login with Google/FB", that's 
  OIDC
  ... I have the same issue with that
  ... that is not what we're talking about
<tallted> OIDC is also not trapped in a G/FB coin-flip
<orie> ^ bingo
  ... when we mean applying auth to these endpoints
  ... we are not talking about integrating OIDC into these 
  endpoints
  ... if people are objecting to SSO, that is not what we are 
  talking about
  ... we are talking about the underlying OAuth protocol
Orie Steele: Take your objects to ODIC to the OIDF :) I hear they 
  have their own way of doing SIOP / SSI :)
Adrian Gropper:  The problem as manu stated, is not with OIDC. 
  The problem is with registration
<tallted> false.
<orie> false
Manu Sporny:  How is it incompatible?
https://github.com/go-oauth2/redis
Adrian Gropper:  The service provider needs a process by which 
  they issue a client id and that process involves some sort of 
  identity verification
Ted Thibodeau: Proof of falsity: http://youid.openlinksw.com/
  ... e.g. if you have a valid credit card, we will issue X to 
  you
<tallted> q
<orie> there is a difference between "authenticating an 
  application" and a "human being"....
  ... the reason OAuth only works in B2B case is because of the 
  client registration requirement
Manu Sporny:  I do not agree
  ... one can set up your own server without needing to use any 
  of the stuff described
  ... to get an oauth client_id and secret, all you need is a 
  webpage
  ... I do agree about the use of OIDC to force the use of large 
  providers
Ted Thibodeau:  The UID link above allows one to set up with 
  sufficient crypto to publish the public portion of your sign-in 
  material
  ... there is no reason to have to use the big 2 or 3 providers
Adrian Gropper:  To Orie's point: the reason for my objection 
  (and the reason to do GNAP in parallel): safety is not the issue. 
  The issue is about privacy
  ... the barrier to client registration is a barrier to adoption
  ... when client registration is introduced, you create a system 
  that is unfair to the subjects
<juan_caballero_(dif/spruce)> but what if all the subjects of the 
  VCs in question are inanimate objects and batches of steel or 
  coal?
  ... the argument is based on privacy not security
<juan_caballero_(dif/spruce)> OAuth is being used to authenticate 
  servers which are passing between them VCs about rocks
Ted Thibodeau:  You rejected my argument because of the last 
  sentence.
Adrian Gropper:  I provided an example that oauth is successful 
  in B2B b/c of client registration
Ted Thibodeau:  Dozens of instances where a verifiable identity 
  does not require a B2B registration
Manu Sporny:  Make sure no one gets too passionate and that there 
  are no personal attacks
  ... would like to collect some data (poll not a decision)
  ... just a +1/-1 poll
  ... start with adrian's proposal
  ... to prioritize working with OAuth2 and GNAP simulaneously
  ... just getting feedback
  ... there will be several pos
Manu Sporny: POLL: Prioritize working on OAuth2 and GNAP 
  simultaneously when adding authorization to VC HTTP API 
  endpoints.
  ... polls
Adrian Gropper: +1
Orie Steele: -1
Manu Sporny: -1
<tallted> -.9
<markus_sabadello> +0.5
<mike_varley> -1; I do not feel GNAP is ready to be worked with 
  yet. But I hope it gets there soon
<eric_schuh> 0
<bblfish> ISn't GNAP a 100 page proposal that is only just 
  started being worked on at the IETF?
<david_ward> -0.1
Anil John: -1 As GNAP is still too immature
<orie> my reason for -1 is that both GNAP is not stable enough  
  to use in production today, and its additional complexity which 
  is orthogonal to our mission
Manu Sporny:  GNAP is in early days at IETF
  ... counter proposal: to prioritize working with OAuth2
Anil John: XACML :-)
<markus_sabadello> XDI link contracts!
Manu Sporny: POLL: Prioritize working on OAuth2 for authorization 
  to VC HTTP API endpoints as a priority 1 item and enable the use 
  of other authorization mechanisms like GNAP, ZCAPs, etc. as a 
  priority 2 item.
<adrian_gropper> - 1
Orie Steele: -1 To getting tangled in lower priority work
<tallted> wording bites me...
Mike Varley: +1 To OAuth 2.0 client credentials, +0.1 for user 
  authorization
<markus_sabadello> 0
<eric_schuh> 0
<orie> "lower priority" means a license to distract and waste 
  call time, but no commitment/
Juan Caballero:  What do the priority numbers mean?
Ted Thibodeau: +1 Presuming *enabling* other authz potential in 
  future is not blocked, is actively worked toward
<orie> at least to me
Manu Sporny:  Very hand-wavy
Juan Caballero:  Recalls concerns about how OAuth2 becomes 
  possible but infeasable at scale
<orie> I would be supportive of "not blocking future solutions" 
  and "not spending time on them other than when they are at risk 
  or having the door shut on them".
Manu Sporny:  What we are seeing is that there is a preference 
  for OAuth2
  ... we are at the top of the hour
<tallted> *nods*  yes, Orie
  ... we will come back to this next week
  ... adrian can you come up with a proposal that would get 
  consensus?
<orie> I suspect that HTTP headers are not going away anytime 
  soon.
  ... we can start with one endpoint
  ... e.g. verify endpoint -- what authZ should it support?
<david_ward> Can the technology used be kicked down the road a 
  bit?  Is it actually important at this time until how the end 
  points fit the use cases are worked out?
  ... we will put aside time for use cases next wee
  ... thank you everyone for your engagement
<bblfish> ciao
Ted Thibodeau: +1 David_Ward
Received on Tuesday, 1 June 2021 23:49:29 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 1 June 2021 23:49:36 UTC