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

[MINUTES] VC HTTP API call 2021-06-29

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 29 Jun 2021 17:51:55 -0400
To: W3C Credentials CG <public-credentials@w3.org>
Message-ID: <a0472235-c0ad-ba01-3582-a92e8891b15f@digitalbazaar.com>
Thanks to Charles Lehner for scribing today!

Credentials Community Group Minutes for 2021-06-29

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2021Jun/0287.html
Topics:
  1. Introductions and Reintroductions
  2. Use Cases
  3. Authorization and RAR Presentation
  4. RAR Q&A
Organizer:
  Manu Sporny
Scribe:
  Charles E. Lehner
Present:
  Mike Prorock, Justin Richer, Andrew Hughes, Charles E. Lehner
  [cel], Mike Varley, Manu Sporny, Adrian Gropper, Mahmoud
  Alkhraishi, David Chadwick, Brian Sletten, Eric Schuh, Butch
  Clark, Juan Caballero, Aaron Coburn, Joe Andrieu, Orie Steele,
  Charles E. Lehner, Kaliya Young, Sanuja (Diwala), Anil John,
  Kevin [Spruce Systems], Ted Thibodeau, Nikos Fotiou, Marty Reed,
  Joe Kaplan
Audio:
  https://w3c-ccg.github.io/meetings/2021-06-29-vchttpapi/audio.ogg

Charles E. Lehner is scribing.

Topic: Introductions and Reintroductions

<juan_caballero_(dif/spruce)> hey andrew!
Andrew_Hughes: most of you know me already, i'm returning from
  distant shores of the internet, starting to pay more attention to
  the w3c work again, glad to hear today's topic
<andrew_hughes> Hi everyone! Glad to be back and seeing what's
  been happening over the last year
Kaliya Young:  Hi, I haven't come to this call before. My handle
  is IdentityWoman; I currently have a formal job role with Linux
  Foundation, ... also Good Health Group, Trusted Health Pass
<orie> Hey David!
David Chadwick:  I've had some change of jobs. Company bought out
  by Crosswords Cybersecurity, now working for them

Topic: Use Cases

Eric Schuh:

https://docs.google.com/document/d/1-u0_Ub6feiX6DH3jXFJFjt6n3CwKGpkmC3VISqDkWL4/edit#
Manu Sporny:  Any updates, Eric or Juan on use cases?
EricSchuh: we are about half way through the scheduled initial
  triage. Expect to have initial set of use cases. If anyone wants
  to add anything new, feel free to. If adding something
  substantial, ping myself or Juan on the Google Doc or comment.
<eric_schuh> contact me via eric@legreq.com
Juan Caballero:  The two uses cases that might not make it into
  the Doc.... separation of concerns use case, different from
  others...
  ... And I'm trying to fool around with a car identity one for
  fun. Please leave comments if interested
Manu Sporny:  This is a first pass, It doesn't mean if not in
  then it won't get it, Just want to iterate over next couple of
  years
  ... Other questions and concerns about use cases before main
  event?
<orie> /me shudders at couple of years...

Topic: Authorization and RAR Presentation

Manu Sporny:  As many of you know, we've been having a long
  discussion about Authorization.
  ... Last week Justin offered to take us through RAR and other
  technologies in the space.
  ... We are hoping to get education for the group, in order to
  make concrete decisions about how to approach authorization in VC
  HTTP API over next few months or longer
Justin Richer:
  https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-05.html
<manu> Slides for this presentation:
  https://www.slideshare.net/zeronine1/rar-and-gnap-for-vc-http-api
<manu> Video recording for this presentation:
  https://meet.w3c-ccg.org/archives/w3c-ccg-vchttpapi-2021-06-29.mp4
Justin Richer:  Thanks very much, I'll start by dropping some
  things in chat. ^
Justin_r apologies to scribe for speed
Justin Richer:  Hi, my name is Justin Richer, I'm in an
  independent consultant based in Boston, but not speaking on
  behalf of clients
  ... I'm hear to speak about efforts I'm involved in that have
  overlap with vc-http-api: RAR and GNAP; i'm a co-editor on each,
  and a bunch of other things over last number of years in
  standards space.
  ... A note about branding: the name of this WG is an absolute
  mouthful. Can we come up with a logo?
<manu_sporny> I love the logo :)
  ... shows VH logo
<juan_caballero_(dif/spruce)> /me hums "panama" under his breath
  ... GNAP: think about what you love about OAUTH2, throw out
  things we don't want, that's the idea of GNAP. Standard track
  ... RAR: rich authoriation requests, backport of .... to OAuth2
  ... Think of it like Scope in Oauth2... also a part of a ...
  working group, in last call right now
  ... Interesting synergy: GNAP not compatible with Oath2, or
  intended to, but since GNAP uses same data structures, can use
  same descriptions if using RAR
  ... Using either GNAP or OAuth2 does not require specific token
  format: separation of concerns
  ... Where's RAR used today? Been in production for a while in a
  number of places. A small slice I was able to get...
Slide 7
Justin Richer:  Interesting that has momentum. People tried to
  add structures to OAuth scope strings; RAR gives you a way to do
  it without all the weird parsing and semantic layering of those
  systems.
  ... Groups looking to switch to RAR to describe access to their
  APIs
  ... Why we're here today: Fundamental question: where/how to
  use vc-http-api with auth delegation protocols
  ... What authorization and delegation protocol looks like...
  ... Three places with clear overlaps between these two efforts
  ... Ability to present things about user without having to go
  through web page like Oauth does
  ... Ongoing question: if presented with VC, how to figure out
  what it's for. How to validate?
  ... Today: my proposal only relates to: the green box (slide
  10)
  ... What is being requested.
  ... Each of these puts the API in a different place. Reason why
  the conversation is confusing
<joe_andrieu> yep. role confusion makes this hard.
  ... People are talking about applications of the vc-http-api
  and delegation protocols, about using it in different ways; they
  are separate layers, separate places in the ecosystem
  ... Need to solve, but not same answer everywhere all the time
  ... What is being requested: how do you describe what you want
  to do at the API
  ... OAuth 1: on or off: got access or not. No way to say run at
  configure time.
  ... Oauth 2: list of on/off flags: scopes. Have scope or not.
  Then people invented different structures for scope values.
  ... We collected and codified to make a rich object, core of
  GNAP, which has been backported to OAuth2 as RAR.
  ... Turns out what people use scopes for go in different
  directions: read access, payments, ...: all get described as
  scopes
  ... Combinatoric explosion when have single flat list.
  ... RAR gives you a structure to describe these things. It's a
  JSON array (like in OAuth2) but filled with objects
  ... Equivalent concept in GNAP is same object.
Slide 16
  ... This is a really good way to solve this with a low lift.
  Not that big.
  ... Each part of this request means something different. The
  type: kind of API you are calling.
  ... Authorization server may protect many APIs with different
  semantics. Even VC HTTP API is not a single API but a collection
  of different APIs for doing different things. That's why the type
  property.
  ... Then we have what you are doing. But since JSON, can extend
  with whatever you want.
  ... If you understand the string, you can understand it.
  ... Has to lead back to human-layer semantic understanding of
  systems.
  ... The RAR type is the key that determines what goes into the
  rest of the API
  ... This is not @context or schema, do not need to fetch. Even
  though URL-based, that is for namespace purposes only. Either you
  recognize the string or not.
Manu Sporny:  Is the expectation that if we use RAR, then this
  group ...
Justin Richer:  That's the next slide
Justin Richer:  Proposal is that this WG defines a set of
  types... how to access the API, in OAuth2 and GNAP.
Slide 19
Justin Richer:  This is the total of what I am proposing that
  this group do. Not that you have to use OAuth2 or GNAP or even
  have to use these; you could use your own scope values, just
  wouldn't be following the interop protocol.
  ... It makes sense to define the API and security model
  side-by-side
  ... It makes you define what you're accessing and how you're
  accessing it.
  ... Better to grow them together, the security model while
  you're defining the API
  ... Rather than trying to decide later ("what is is that we
  do?") - and has to be done eventually.
<identitywoman> straw people!
  ... Now for strawman proposals for a lite take on what this
  could look.
  ... If you are going into field values, you're missing the
  point
  ... Want to see how you could apply the RAR data structures to
  an API like this.
Mike Prorock:  Question about "you all" this community defining
  and implementing this stuff. Are you proposing to lead this work
  defining this stuff, or what's your vision here?
Justin Richer:  I'm not
  ... I'm trying to connect the dots for this community. I can
  definitely contribute to this, but not that I am going to come in
  and insist that this group do or on a particular solution. Not
  the purpose of this presentation
Mike Prorock:  Thank you
Justin Richer:  Straw man (people) proposals. Try not to get tied
  up in the details.
  ... Different parts of the ecosystems: Five main access types:
  I call them issue, verify, construct, fetch, and present.
  ... Issuing a credential: want to differentiate between asking
  someone to create something, or take something and sign it.
  ... There are already multiple dimensions for a type like this.
  The type that talks about vc-http-api's "issue" action; and then
  there are multiple actions: if something asks for both, I could
  limit; or limit to particular server location
  ... Likely other dimensions to all of these, including some
  specific to VC HTTP API.
  ... That is the type of stuff this group ought to be defininig.
  ... Verification API: looking to verify something, the
  presentation and its content. May have different rights
  associated with them.
  ... It's important to look at the API and slice up the
  different levels(?) of access people might ask for in different
  ways.
  ... Construction: when asking people to do construction step,
  might ask someone to disclosure particular fields. Disclosures
  are not defined by GNAP but would be by this group. No need for a
  schema, but designed to be scoped to the particular API being
  protected. Lots of flexibility for how to describe access to
  things.
  ... Presentation: what are the things I'm allowed to present;
  credential, presentation.
<orie> here is an example of "older" style scopes...
Orie Steele:
  https://developers.google.com/identity/protocols/oauth2/scopes
  ... I'm not expecting details of this to be accurate, but
  expect you to see: VC HTTP API work: different things I want
  people to be able to do, and how to differentiate
  ... Recmmending WG adopt this work, define types, say what are
  the dimensions needed and what do they mean. ... Add normative
  type definitions to the document.
  ... Say e.g. the API must be protected by an authentication
  technology applicable to VC HTTP API - don't leave it open - if
  authorization is appropriate
  ... Say recommend protocol like GNAP for specific endpoints;
  list out the fields and what they mean.
  ... People understand OAuth, could use that to protect their
  thing.
  ... Someone else could use MTLS: go ahead, that's still
  protected, perfectly legitimate.
  ... This I think is the key limiting factor lost in the
  conversation before. Not saying you must use GNAP, nor that we
  should be solving the whole rest of the authorization problem.
  ... Email to list earlier this week had questions like "what is
  the lifecycle of this token": put out of scope; not in the
  concern of the API being protected
  ... But API should be able to describe how to ask for access to
  it, using standard technologies.
  ... I believe it's a very light lift, as already describing
  anyway
  ... And beneficial to people who would like an interoperabile
  security layer(?) on this API.
  ... End of presentation
<tallted> sorry; came in late; link to deck?
Charles E. Lehner: Orie: I agree, especially about out of scope.
  Huge +1
  ... Diagram showing people putting VC HTTP API in different
  places. It's worse as we we haven't really defined what this API
  is. My question for folks who successfully implemented RAR...
  ... I wonder if you have an opinion on the best way it should
  play out
  ... Should define a restful API and then define the RAR
  permissions scopes for it? Or define the scopes and then the API?
  ... If scopes refer to API, can't you not define scopes before
  API?
  ... I could see building both at same time, or API and then
  scopes later. Which yields better outcome?
Justin Richer:  Defining them together. So you can refine both
  sides as they grow up.
  ... As you said, this group is still getting its edges defined
  about what is the VC HTTP API
  ... Good time to ask: is this a different... type of access, or
  is it subsumed by something else?
  ... Allows you to take an iterative approach
  ... Other reason: people will need to define it somewhere, to
  deploy
  ... People would build different things slightly incompatible
  about actions. i.e. some may say issue and sign are the same
  thing, but it may be an important differentiation to someone else
  ... Conversation might not happen until after people already
  put down stakes

Topic: RAR Q&A

Orie Steele: +1 I generally agree.
  ... If you don't do it now, it will happen later
  ... People will try to shuffle it out somehow, whether or not
  this group does it, but won't be as good if this group does not
  design the security layer.
Manu Sporny:  Current slide (11): question to group: I think it's
  a really good way to frame what's in scope
  ... Green box in scope, Yellow/purple out
  ... I would like to see if we can pass those resolutions today
  ... Question to rest of group: if we pass today saying yellow
  box out of scope, purple box out of scope, would anyone object?
Joe Kaplan:  We need to define other than colors
Orie Steele: +1 Joe
<juan_caballero_(dif/spruce)> /me objects on behalf of the
  colorblind and blind listeners :D
<tallted> I don't grok the boxes sufficiently to say yes or no
Manu Sporny:  We will; basically interactions between
  authorization server and resource server - out of scope
Justin Richer:  If I may try to categorize that: something I've
  been trying to convince this group of for a bit: the orange box
  represents VCs presented to an Authorization server.
  ... Purple box represents VCs presented to an RS that the RS
  (Resource Server) needs to make sense of
  ... Green box represents accessing the VC HTTP API, by
  something.
<mprorock> I am going to point out that this is not really how we
  use VCs all on our side
  ... Protection of access to the VC HTTP API itself ought to be
  in scope for this group to handle in an interoperable fashion
<orie> green box is clearly in scope.... other boxes appear
  generally out of scope.
Manu Sporny:  Got it. If you can figure out how to put that into
  concrete text for a proposal, that would be helpful
Justin Richer:  Did scribe right it down? That's what I thought I
  was doing
S/right/write/
Ted Thibodeau:  I'm hoping to get a link to the deck
Justin Richer:  Not hosted online, sorry
Ted Thibodeau:  Could it be?
Justin Richer:  Possible
Kaliya Young:  You could watch the video
Justin Richer:  I did not write this as a leave-behind artifact.
  ... Without the audio, much is missing
Ted Thibodeau:  Video will cover it.
Mike Prorock: +1 Ted
  ... I won't be able to vote, there is a lot of hand-wave
Manu Sporny:  Objection to proposal?
Ted Thibodeau:  At this point, yes. It would need to be better
  defined.
Manu Sporny:  One thing we could do is put it to the mailing list
<juan_caballero_(dif/spruce)> scribest with the mostest

PROPOSAL:  another entire call dedicated ONLY to green box.

Orie Steele: +1 Justin to keep talking about ONLY green box
Justin Richer:  To follow on Orie's comment, I'm saying the green
  box should be the topic of a call and for the working group as
  many calls as it takes
Manu Sporny:  We just need to get resolutions down
  ... Trying to make sure we have everyone onboard so we don't
  just talk about the yellow/orange box and just talk about the
  green one, to put the debate to rest and move on.

PROPOSAL:  It is in scope to define a means of describing access
  to the VC HTTP API, using RAR/GNAP.

  ... Up to you, if you want to put a proposal, TallTed may
  object, but we could discuss on mailing list
Manu Sporny:  There is one in there ^
Ted Thibodeau: +1 To mailing list discussion. And to scope
  clarity! I just don't quite grok what's here.
Mike Prorock:  Clarifying point, about banks using RAR, thinking
  about practical life and dealing with my customers... Of the
  major providers for Oauth2 - Okta, Ping(?), etc., who are using
  it out of the box?
Justin Richer:  I don't have an answer, am not a salesman or an
  integrator

PROPOSAL:  it is out of scope (for now) to define a means for an
  authorization server to request, accept, or process the VC HTTP
  API.

<mprorock> What about:  "It is in scope to define a means of
  describing access to the VC HTTP API"
Orie Steele:  Green box: initial proposal said RAR/GNAP. As I
  understand this green box, it's about using RAR to get an access
  token "scope" correctly, then passing the token to a resource
  server...
Justin Richer:  Not that much; it's about describing how to get
  the access token, and how to access what's described in it
Orie Steele:  Lower part...
Justin Richer:  ... Not saying specify that...
Orie Steele:  This is VC HTTP API, one place to put access token
  is in headers
Justin Richer:  VC HTTP API could say that; there are a bunch of
  ways to present access tokens and their equivalents
Orie Steele:  That area is probably less controversal. If trying
  to break it down for folks on call or mailing list... In my
  opinion, concern is about the top arrow, that's where all the
  pain and confusion is.

PROPOSAL:  it is out of scope to define a mechanism to use the VC
  HTTP API to prove access to a given RS.

  ... This bottom arrow is typically a standard thing; in HTTP,
  in DIDComm, how you use it is covered conventionally
  ... How you get that is covered by RAR?
Justin Richer:  Incorrect. The mechanism of getting the token and
  of using the token are defined by Oauth2 and by GNAP.
  ... The mechanism of describing what you want that token to be
  able to do is the one small piece that I am suggesting this group
  work on.

PROPOSAL:  The vc-http-api will use OAuth2.0 + RAR

Justin Richer:  Then what's the format of the token? What's in
  the token? I don't care, and neither should the spec say anything
  about it. It should be deliberately opaque to this specification;
  obviously not to a particular deployment, but for this
  specification I don't care.
  ... The only thing is that I have software that knows how to
  call VC HTTP API; it knows what it wants to do and wants to ask
  for permission to do that. How do you encode the rights in a set
  of actions in a request?
<orie> There are 2 options here... OAuth2.0 + RAR or OAuth2.0 +
  Scopes
  ... RAR does not tell you how to get an access token, but says
  a way to describe what it ought to be good for.
<orie> we already resolved not to mention gnap iirc
Justin Richer:  Does that clear things up? It's a very narrow
  thing I'm proposing
Mike Prorock: +1 Orie - question is really around scopes or RAR
<justin_richer> RAR == scopes
<orie> correct, imo
<justin_richer> I;'m trying to make that point!
Juan_Caballero_(DIF/Spruce): I was wondering... in the examples
  you mentioned disclosures as an example of an API-specific
  object, you said it's in a registry but it wasn't clear... Are
  you proposing that per API this spec would include optional or
  mandatory definitions of what disclosures or other types of info
  specific to VC HTTP API that could optionally be in the token?
  ... Is that something this group could say... if it's this kind
  of use case, use this kind of disclosure? Is there a table we
  could right?
<tallted> Will this be OpenAPI spec'able? Or is this forcing
  human interpretation and no machine
  discoverability/operationality?
Orie Steele:
  https://developers.google.com/identity/protocols/oauth2/scopes <-
  this isn't rar right?
Justin Richer:  It could, that's what I'm trying to say.
<orie> hence my point, not helpful to call "RAR" === "Scopes"
<juan_caballero_(dif/spruce)> i DO love multidimensional giant
  tables!
  ... When I've done work like this in the past, we had giant
  tables of OAuth2 scopes, about health sensitivities and other
  stuff we had to spell out... because we were writing to a
  specific API.
  ... This group has the opportunity to try to write for a
  specific API rather than try to patch it in later. Much
  preferable.
Mike Prorock: +1 Orie -
  https://developers.google.com/identity/protocols/oauth2/scopes is
  what most of us writing commercial software
<orie> imagine a world where enterprises use OAuth2.0 + scopes
  today.
Juan_Caballero_(DIF/Spruce): I find this all very interesting,
  just wondering if there some sort of fallback or equivalent for
  how a table written for RAR could be encoded in say scope strings
  or something else people don't like?
Justin Richer:  Yes, lots of bad ways to do that, I've
  implemented and deployed pretty much all of them
<mprorock> lol @orie
<mike_varley> @orie the google ref; no, that looks like an
  implementation using rigid strings, that RAR looks ro address
  with an expression language. (my 3s interpretation)
  ... I've seen people do fully articulated URLs as scoep
  strings, hierarchical scope strings, JSON objects as scope
  strings.
  ... The question is whether you need the ... in the first place
<orie> RAR = Fancy Scope Strings.
  ... Every single object in RAR could be represnted by a scope;
  that's where the combinatorics blows up.
  ... Say you want to be able to ask for read access in one
  location and read/write in another location. How to tie them
  together?
  ... RAR gives you the framing structures to be able to say I
  want read here and read/write here.
<orie> I try :)
  ... Yes, RAR is fancy scope strings. That's the correct
  takeaway.
<juan_caballero_(dif/spruce)> thanks for that answer! helpful
<orie> what if we decide to use OAuth2.0 + Scopes
<orie> but all our scopes
<orie> are JSON.stringify(RAR)
<justin_richer> Orie no
<orie> :p
<juan_caballero_(dif/spruce)> Orie stop it
<mike_varley> lol
Manu Sporny:  Adrian, what variation of this removes your
  objection? If we were to adopt something, e.g. Oauth2 and RAR,
  would you feel comfortable with us addressing the delegation and
  attenuate use cases?
Adrian Gropper:  No, this has nothing to do with my objection.
<tallted> "RAR = Fancy Scope Strings" -- are those *strings* or
  can they be URIs or whatever else?
<mprorock> let's just json.stringify everything
<orie> cut me :)
  ... I think this is a fabulous idea. With the HART(?) WG (which
  UI was also in) - I know where the bodies are buried, maybe from
  a different perspective than Justin, but this does not address
  that
Justin Richer:  Adrian, this is why I was trying to make it clear
  with the different boxes. I think the things you have brought up
  are firmly within the purple box.
  ... I get this VC thing and want to use the API...
  ... or... I want to take actions to get stuff. Separating these
  concerns is the first step to addressing them.
  ... Whether in this WG or not is a separate question. But need
  to call these out and put boundaries around them so that people
  are not talking past eachother
Adrian Gropper: +1 That my concerns could be addressed elsewhere
  if we keep OAuth out of VC HTTP API
  ... I think all of these boxes are important. Personally think
  the orange box is far more interesting. But doesn't mean it's the
  right forum for solving this specific issue. That means we have
  to find that forum to have that conversation.
Ted Thibodeau:  RAR is fancy scope strings: are those just
  strings or can be URIs?
Justin Richer:  They are JSON objects.
<orie> hence my joke about stringifying them :)
  ... I was responding to ... glibness.
<mprorock> agropper - oauth is in the real world - we have to use
  oauth and are using it already with the vc-http-api
Ted Thibodeau:  Everything I saw had just keywords, not appearing
  to expand into URIs
Justin Richer:  It doesn't, I didn't say it would
Ted Thibodeau:  My concern: appears to not be machine-addressable
Justin Richer:  Correct, that's a design goal; intentional
<orie> Ted ask him if he likes linked data... :)
<butch_clark> Thanks Justin - Very imformative
Manu Sporny:  Thank you Justin for taking the time to put
  together this presentation for this group
<justin_richer> thank you for the scribe! I know I am very quick
<juan_caballero_(dif/spruce)> thanks! this really helps
<mahmoud> Thanks justin that was great!
<orie> Thanks justin, this was excellent.
<mike_varley> Thanks scribe! well done. And thank-you Justin.
<juan_caballero_(dif/spruce)> and CEL OMG
Manu Sporny:  Thanks scribe. Thanks everyone.
<brian> Thanks Justin
  ... Let's take it to the mailing list. A number of concrete
  proposals we could put to the mailing list.
  ... Hopefully folks got an idea of what using RAR could look
  like.
  ... We'll make the video available; people can look through it
  again. Let's go ahead putting concrete proposals on the mailing
  list.
  ... We'll run some of them on the next call
<joe_andrieu> Cheers!
  ... Have a great rest of week!
Received on Tuesday, 29 June 2021 21:52:19 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 29 June 2021 21:52:20 UTC