Joe Andrieu: I've noticed in last half hour theres a thing missing i'll get to ✪
Joe Andrieu: Each of the participants who are in a different trust domain have different colours ✪
Joe Andrieu: Messages that cross these boundaries need authz ✪
Joe Andrieu: Often these are "i only accept access from localhost" ✪
Joe Andrieu: We are identifying where we need to talk about authz ✪
Joe Andrieu: Emerging definition for service and app. the distinction between server, app and role. roles: holder, verifier, issuer. different components: app is software or service that gives vc-enabling capability (often SaaS) ✪
<michael_herman_(trusted_digital_web)> role -> Actor
<michael_herman_(trusted_digital_web)> Roles are not actors in most formal modeling metamodels
... service is only accessable by the app
<manu_sporny> I like this direction...
<michael_herman_(trusted_digital_web)> Actors are assigned to Roles but Actors are the only entities that perform actions.
... we have previously conflated the role and app and this is separated now
<dmitri_zagidulin> it seems like the Verifier Storage Service doesn't add much to the diagram. (plus, many verifiers won't be storing the VC, etc)
Michael Herman: Role could be changed to actor? formal document should use formal definitions ✪
<orie> > holder
<michael_herman_(trusted_digital_web)> These are personas
David chadwick: in the model we've got we differentiate between application layer and VC layer. when we talk about app that could be browser on mobile phone or 3rd party banking app which talks to holder app. on relying party side we have service provider which will talk to the service ✪
Adrian Gropper: I understand the role of holder and issuer are separate roles but from authz perspective they could be combined in some instances. when we have distinction between device bound identity and biometric bound identity the opportunity arises for combining issuer and holder as theres no need for device bound identity ✪
... when liveness is required that can also fit into authz protocol
... where the resource owner needs to be in control of authz policies instead of storage that is where my perspective is
Joe Andrieu: Slight shift in language might help me understand ✪
<orie> this picture does not include Issuer... it assumes that the holder already has a VC... we don't care how that happened.
... any entity may be in any role at any time. that flexibility is innate. any of these services could be monolithic. reality is for our API important things are where do we provide APIs that can have substitutability
... an entity can have multiple roles. trying to find API that enables substitutability
<mprorock> I would love for Joe to be able to walk through his and Eric's work on this use case, then have a discussion about it honestly
<manu_sporny> ok, we can do that mprorock
<mprorock> with a big caveat that we are talking system to system use cases here
Adrian Gropper: I understand substitutability give challenges across trust domains. when discussing issues around delegation it would be helpful to our conversation if we considered when substitutability is important from a human rights vs vendor lock in ✪
<orie> i'm not sure why we are allowing the unrelated conversations to persist in this work...its confusing and harmful.
Joe Andrieu: I think that's right. most of the difference was the idea of data ready going to the service where really that is clicking on jobs website in the chapi flow ✪
Ted Thibodeau: On the flow for who checks status, both holder and verifier should do it ✪
... i don't want to submit a revoked vc if i can get a new vc that i can submit instead
<manu_sporny> q
<orie> thats because all VP flows require domain and challenge to be exchange prior to VP construction and communication.
David Chadwick: In openid connect: i can see how this maps into OIDC. message 3 would be the user talking to the resource to say i need access. message 6 would be the resource sending the presentation request which would detail the VCs it wanted ✪
... the user would retrieve VCs and then 13 would submit VP. 19 would say you have access go ahead
Adrian Gropper: In supply chain flow, difference between VP and VC is liveness detection a concept or is it assumed that there is none but only detection of holder that is meant to be the difference ✪
... you can sign a challenge w/ liveness or just by signing
Joe Andrieu: That is the primary difference, i wish the supply chain had anchored the VP to the current user but that is not how it has been fleshed out ✪
Joe Andrieu: Problem domain does not contain liveness detection ✪
<orie> it turns out that APIs exchange data... without people being detected as being alive, or involved.
<dmitri_zagidulin> I think it might be worth clarifying that VPs only need challenge & domain when used for authentication. But not really for other purposes.
Adrian Gropper: There is difference between supply chain and general VP use case ✪
Joe Andrieu: Same sort of walkthrough and look at differences. how are we going to talk about authz at these levels. often holder authenticates to app using email ✪
Joe Andrieu: Lets do chapi and that can flow into how are these layers secured ✪
Orie Steele: I will object to language that uses SHOULD to imply people will use something that's not possible to use ✪
... this specific text: i will object to PR if it contains SHOULD or MUST
Ted Thibodeau: We are using SHOULD in the RFC explanation: do it unless you have a good reason not to ✪
... MAY to warn the other side you might do something
<orie> MAY does nothing... exactly... better to do nothing... than to do something harmful.
... SHOULD is a strong do it please but you're not in violation if you dont
<orie> it is impossible to render GNAP RAR in OAS3.0... its not supported.
Adrian Gropper: I don't think we're ready to talk about this because: 1. we can not reply to a human rights argument using economic reasons. 2. not sure what is impossible, for example UMA we built delegation onto OAuth ✪
<justin_richer> Orie then you have bad tools ��♀️
... we need to have human rights conversation in regards to delegation
<mprorock> that is fine, but let's take that to the mailing list, not this work item for now
<justin_richer> Also, I adapted it to do just that, since it's open source. It just doesn't allow plugins because of the software design.
<orie> I have tools that enterprises are using... i think you might have a spec that nobody has adopted yet.
<davidc> I wanted to say that we may have different authz delegation rules for the different APIs (verifier, issuer and holder) and the current text does not differentiate
... respec auto-generator from OAS file
<justin_richer> OAS3 is a tool -- treating it like a requirement is putting shadow dependencies into the spec, and that's just bad design
... this thing existed as OAS files before this spec existed. desire to keep OAS
<orie> thanks for your opinion justin, but we agreed to use OAS3.0, that point was already resolved.
... there was no mechanism to inject OAS into respec
<justin_richer> Using it and depending on it are different things and you're hiding behind that to support your argument.
... code that pulls in OAS and renders into respec
... schema is rendered directly from OAS. it's json and hard to read. renderer needs to be updated
<orie> Justin, i'm not hiding behind OAS3.0... i am using adopted industry standards to strengthen our work item, and its potential for adoption.
<mprorock> @manu - this is great
... the hope is this a general solution that this will work for any REST api within CCG
<orie> @manu looks great!
... it would be awesome if folks would help me with the code