... there are three diagrams here that provide more detail of this, and references other APIs that are out of scope
... so some amount of discussion is needed before we can "incorporate" or map which parts of those additional diagrams can be incorporated
... issuer detail diagram - breaking down issuer services/components shows what the internal API is conveying between them
... application logic and business logic in that app service
... which cannot and should not be standardized or overspecified; this API is standardizing the links between low-level VC operations
... these three boxes back here on the left are what can be standardized loosely:
... the "backing database" is well outside the scope here but can be generalized and its interface assumed/specified
... we are calling all these interfaces internal because they are all under the control of a single issuer
... pause for questions
Orie Steele: Technically everyone in the internet can hit them today, since there is no authorization framework for them. :) ✪
Adrian Gropper: So the VC-HTTP-API is invisible to the holder? it could be any of the above? ✪
Manu Sporny: Almost-- for the internal APIs, that is accurate; the complexity comes in when we talk about externally-exposed or cross-boundary APIs and VPs ✪
"Presentation part" of what happens in this API specification is where that stuff will happen ✪
Orie Steele: +1 Adrian, the subject has no interfaction with internal systemss ✪
Orie Steele: How apple manages your biometrics is outside of your control :) ✪
Adrian Gropper: I'm not sure how this technical clarification helps answer my human rights question; not sure how to evaluate this issuer/subject relationship in terms of rights ✪
Manu Sporny: We'll return to the holder in a minute, it's a set of questions i prefer to address separately ✪
<agropper> access is restricted
... we are not just trying to levelset on terminology and architectures in scope at high level
Orie Steele: +1 To adrian's concern: we should address AuthZ in both internal and external situations ✪
... internal authZ = am i talking to the right component within my systems, external = am i talking to who I think I am in someone else's security perimeter
... i think keeping those two sets of requirements explicit will be helpful throughout
Manu Sporny: Yes, +1, we should address authZ before getting consensus that these diagrams are good to go ✪
... hasn't been discussed in depth in this group but i am proposing we return to it soon by saying for now that authZ will be ASSUMED
For all these endpoints and therefor in all these interfaces ✪
<orie> I don't feel like its necessary as long as folks understand that its required for secure operation
<orie> and currently absent
... unless people think exactly what kinds of authZ need to be discussed now
Orie Steele: I'm fine with it being an explicit but unspecified assumption ✪
... i just want to make sure the potential for impersonation is mentioned so readers are reminded it has to be addressed separately/before working on these API details
Adrian Gropper: I think we need to talk about the narrow waist again ✪
Topic: Authorization Tarpit
... because it is a blocker to aligning with SDS work, authentication/SIOP work, the WACI-PEx/credential-exchange work
... it is a cross-cutting issue and foregrounding it now will be a stitch in time
... by "the narrow waist" i mean whether the messaging or the transport is the narrow waist
Heather Vescent: I am wondering if Alan Karp's use case could flesh this out ✪
<orie> I don't think "authorization standards innovation" should be in scope for this work item.
... i am worried an abstract discussion in advance of authZ in general would slow us down, versus organically wortking through it in the use case considerations
Manu Sporny: I agree, there is lots of authZ in the use cases that are looking central ✪
<heathervescent> That all sounds good to me.
Orie Steele: I am worried it won't be succesful without a little agreement in advance ✪
... to me, the divide is between people who want to discuss and implement future authZ schemes and people who need authZ today
... i do not think ZCaps or GNAP are appropriate for this scope and OAuth is because we need to descope draft specs and future implementations in favor of something already available, standardized, and implemented today
Mike Prorock: +1 Orie - we know that at least OAuth will be in play ✪
Manu Sporny: I don't see that as so controversial, we could run this as a proposal soon ✪
... using what's built today as one option among many should make sense for writing a spec today, but with strong statement on maintaining possibility of specs coming soon
<agropper> OAuth has failed in the human right arena
... would anyone object?
<agropper> I would
Orie Steele: -1 To the only usable standard for authorization is a great way to keep us from getting a useable api... if your goal is to be authorization philosphers I suggest we hold the door open for everything. ✪
<orie> an maybe we can change the work item title to "considering authorization drafts that have few implementations"
Mike Prorock: Strong +1, many existing implementations are already using OAuth tody ✪
Adrian Gropper: I have been trying for a decade to profile OAuth and UMA to work in an SSI way, i do not think it is possible, i think OAuth is dead and its authors have moved on and want to work with this community on future specs ✪
Mike Prorock: My company and many others are using OAuth today to handle VCs, not because it's optimal or the best aligned with SSI long-term goals, but because it gets enterprises consuming VCs ✪
<orie> expect to keep getting derailed by authz until we define scope better.
Manu Sporny: OK i think there is a manageable amount of disagreement here but not on the core issues, let's get back to diagram alignment ✪
Topic: Issuer Architecture Diagram
Juan Caballero: On the contrary i'm grateful for this starting point ✪
Orie Steele: Might be semantics, but I'm wondering if i understand correctly the issuer website caption in this diagram ✪
... would "web service" be more precise than "Website"?
... are holders only interacting with websites or should it be more generalized to HTTP-based in general?
<agropper> Is anyone else having trouble getting into the doc?
Manu Sporny: I think you're right that langauge could use a little work. proposals? ✪
<mike_varley> "web service" ?
Orie Steele: Unfortunately we already used "issuer service" ✪
<mprorock> "web gateway" "web service" "web service gateway"
... ^^
Mrprorock: i think "gateway" would help as a term here, because it can include a website and/or system-to-system REST-style APIs ✪
... most verifier perimeters would include issuer components from previous diagram, but doesnt need to be explicit here because it will look like a requirement
... again, an app service box is an umbrella term for all kinds of business logic and validation
Orie Steele: I think the same nits are worth picking here, but the structure is great ✪
... one question i see in various VC exch contexts
... is this: does the verifier have PKI requirements? does the verifier need to do anything more than *just* verifying a VC as per the spec and our API thus far?
... many proposals I've seen require verifiers to have key material of their own
... and impose requirements on verifiers that should be considered
Manu Sporny: Good, this is a topic worth discussing ✪
... your point about cryptographically-secured versus insecure challenges
... are those challenges local to the application service, or should it be accessible to the verifier service?
<dmitriz> ok so, step one, write down the challenge on a sticky note, stick to server rack. step two, point camera, apply machine learning to recognize the handwriting... piece of cake.
... are challenges passed around between components before and/or after external interactions?
... shoudl this API have opinions about the role of challenges?
<dmitriz> manu - think of it as an education opportunity! if somebody asks "huh what's a presentation?", you can be like WELL, let me tell you ALL ABOUT IT
Manu Sporny: I think it would be redundant to too many other groups to specify VPs ✪
... but we need to discuss it a bit
Orie Steele: We are specifying it at least a little just by talking about it; i think it is in scope and useful to have opinions about VP ✪
...specifics that this API assumes/requires
<orie> noting that DIF PE supports other protocols
Adrian Gropper: May be off topic but where are audit requirements in this API's design? ✪
<orie> whereas vp request spec is currently only implemented in CHAPI.
Manu Sporny: That sounds like a good github issue ✪
<orie> we have an implementation of it in trace interop
<orie> but are likely going to replace it
<orie> eventually
<orie> especially give the challenges with interop with the other protocols that are created by not using DIF PE
<phil.l> many issuers are interested in the use of the credentials they create and holders then package and send as presentation.This is understandable, and at the same time problematic for privacy. A point to consider in the audit question.
... lots of the "digital wallet" component here is out of scope but has lots of the consent and individual intervention capabilities
Orie Steele: I'm not sure you meant what you just said ✪
... about the univ wallet
... i'd rather back up a little and address scope
... If a use a wallet to manage keys
... i need an API to reliably do these cryptographic exchanges with other parties
... and a standardized API helps you trust the client's management of keys and secrets
... i.e., it helps strengthen the gap between trusting client to hold a session/auth token and trusting client to manage a wallet's keys
... calling it "create VP" and "derive proof" is great, but the arrows going to other parties (iss and ver) is a little confusing because former is internal and latter are external
Adrian Gropper: I think i'm going to repeat Orie, hopefully, but my objection to this diagram is that it combines credential storage and authZ mechanism/control of those credentials ✪
... whereas separating those two concerns helps privacy engineering
... even if the two are separated as two boxes within the holder boundary that would help me express them as distinct
<phil.l> There are use cases where the reason someone would do the presentation creation is external is that they are doing so from cloud-based client. This is an equity issue if a cloud service can't be used. I recognize the security & privacy implications...
... speaking to KMS and EDV and AuthZ rather than over-abstracting or over-simplifying them
<orie> if it helps I can speak to Universal Wallet Interop spec, and how I see it supporting the vc http api not replacing it
Manu Sporny: Maybe "holder DB"/EDV/storage mechanism should be a separate box again ✪