...sorted into categories: well-formed, partly-formed, and out of scope
... we also tagged all the people in the "needs work" category asking for updates. if we don't get feedback, we'll edit more aggressively but we strongly prefer more input from all of you
... this was just a first pass, out-of-scope category
Juan Caballero: No other updates from me, it's never too late for input, please help. [scribe assist by Manu Sporny] ✪
Eric Korb: Out-of-scope may change and up for debate, and today's discussion may help make those calls ✪
<manu> This is a proposal to Restrict conformance and interop test suites to did:key only.
Orie Steele: Conformance tests require a tested system to support certain cryptographic capabilities and suites ✪
E.g. Ed25519; examples and test vectors that rely on outside servers, external resolution processes, etc can be quite difficult and add friction ✪
... we discussed "mocking" and "stubbing" on last week's call, and this sidesteps that issue by using DID:Key (which is memory-based and does not require external network calls, DID resolution, ledger availability, etc)
... this could be argued to be lazy but for better or for worse this allows us to focus on signature verification and ver methods
Manu Sporny: Last week, the resolution to mock up DID resolution got a fair amount of support, and the resolution to just use DID:Key seemed to get more ✪
<manu_sporny> PROPOSAL we could run: Refactor the test suite to support did;key as the only mandatory DID format for the test suite.
... i would like to re-run the proposal today to make it a resolution
Orie Steele: The issue specifically limits this to CONFORMANCE tests ✪
... i.e. conformance to the API.
...I think interop tests we shouldn't limit to DID:KEY, just the API conformance tests
<manu> Define schema for response of /credentials/issueCredential
Manu Sporny: Orie can you summarize for the group? ✪
Orie Steele: I think this thread stems from the ongoing confusion about internal/external APIs and trust boundary assumptions ✪
... I think it's mostly outdated, not too many ongoing open questions here
... I think there were some resolutions taken?
/Me is there a quick way to overview the resolutions taken by the group since we started holding public calls without paging through all the minutes one by one? ✪
Mike Varley: +1 To marking it pending closed; not sure if George will be following up (he has moved on from SecureKey) ✪
... a good way to close would be to mark it pending closing and link to relevant commits and/or resolutions on scribed calls
Orie Steele: Summary: RESTful API industry norms were the starting point (controller style) ✪
... complete consensus, as I remember it, that these terms were a good starting point and that RESTful APIs were what got us here
... although I don't think we've taken official resolutions anywhere, and I worry we will keep relitigating these style guide decisions without some kind of resolutions to point to
Orie Steele: I'd say that the resolution should be best-practice conformance where deviation not resolved via GH Issues, and "controller"-oriented naming ✪
<manu> PROPOSAL we could run: In general, the VC HTTP API style will conform to restfulapi.net guidelines and specifically use a 'controller' style for endpoints and will use JSON Schema to define the acceptable inputs to the APIs. Any deviation from these guidelines will be discussed in the group.
Orie Steele: Data modeling requirements versus RESTFul norms: revocation, for ex ✪
... collection-oriented RESTful APIs may require an issue for revocation
Manu Sporny: Sure, sounds like a good first issue ✪
...if it passes
PROPOSAL: In general, the VC HTTP API style will conform to restfulapi.net guidelines and specifically use a 'controller' style for endpoints and will use JSON Schema to define the acceptable inputs to the APIs. Any deviation from these guidelines will be discussed in the group.
RESOLUTION: In general, the VC HTTP API style will conform to restfulapi.net guidelines and specifically use a 'controller' style for endpoints and will use JSON Schema to define the acceptable inputs to the APIs. Any deviation from these guidelines will be discussed in the group.
...#204 , named `Revocation List and Restful APIs`
... I think it's important to note a few things about this example: `id` isn't strictly mandatory, and revocation methods that rely on `id` we're getting into terrain not covered by the core data model
... and shaky assumptions like "all VCs have an `id`" or "all `id`s are collection-style URIs" can get us in trouble
... so this is a potential conflict between collection-style and controller-style API design patterns
... or at least, an illustrative example of a caveat to the RESTful design patterns that got us here
Topic: Authorization Proposals
Markus Sabadello: I have thoughts and I'll put them in the issue but I just wanted to chime in to say that this has come up along the way and this sounds like a good discussion to have here ✪
Manu Sporny: I want to get to proposals discussed over the CCG list ✪
... should be able to have delegated caps recognized and processed where present
<tallted> +0.5 "when those technologies are properly fleshed out and vetted"
<justin_richer> ^-- TallTed right, that's what I meant
<justin_richer> oh wait, that's apparently not what I meant
<orie> it would take time and adoption for me to change from a -1.
Mike Prorock: I think i'm in agreement with Tallted that assuming the commitment now before we know what form these technologies will have once they're mature and adopted in the market... I don't like the chronology of this commitment ✪
Orie Steele: I have nothing against these technologies and where they're going, but not today, not in its current form and level of adoption ✪
<orie> lets reformat the proposal to limit it to RAR then
Justin Richer: I'm not saying to create a GNAP profile here, just for a specific application ✪
Orie Steele: I agree that scopes are not a great fit ✪
Justin Richer: The RAR work is in WG last call right now, will be an RFC soon ✪
<orie> much further along than publicKeyMultibase ; )
<tallted> maybe rich-authorization-requests should be added to the list of `Such as`? ... and one or both the others removed? ... and we should come up with some kind of rubric by which to analyze and compare delegation "frameworks" (right term?)
... and I think that is pretty mature by objective standards and adoption metrics
... I think "scope strings" in OAuth is exactly what RAR is a great upgrade
Adrian Hope-Bailie: A big +1 to making sure the group is clear on what Justin means about RAR versus scopes (as opposed to adopting all of GNAP, for example) ✪
<orie> lets see how much of GNAP or RAR we can take in isolation... maybe with some better clarity, we can actually understand what we are voting on, but I'm a -1 right now, don't understand what this is going to do in terms of requirements for enterprises / banks
<justin_richer> @mprorock RAR is a backport of GNAP's authorization model (ie, scope equivalent) to OAuth 2
<mprorock> @justin - yes
<justin_richer> again, it's on OBUK
<justin_richer> and I don't represent the open banking community at large
Orie Steele: OpenBanking and RAR might be a good use-case walkthrough ✪
<mprorock> but in use via oauth - that is the key thing for me
/Me would like to see the API docs or example calls that these open banking people are using? ✪
Orie Steele: I think an open-ended commitment entails unbounded complexity, a scope-limiting conversation about how RAR could work (and is there a way to use RAR without GNAP, for example) ✪
... and I'd like to hear about how okta or auth0 configurations have to be modified
...to do this
Justin Richer: I worry that I'm restating what I thought I'd already made clear? ✪
<orie> I would be more likely to support scope strings than RAR or GNAP.... based on my experience with the adoption and comprehension of scopes...
...Strawman: if we were to say here is an API, if you have secured it with OAuth2, put "readvc" into the scope string so that everyone uses scope strings the same way. no one would call that adding complexity, but simply pragmatic standardizing of an abritrary string
<tallted> or! `use scope string http://example.org/readvc` which can be dereferenced to learn its meaning in or out of context
... I am saying that there is a RAR form and a string-scope equivalent and we can write both into the spec without adding the kind of complexities you guys are worried about
Manu Sporny: None of us have implemented RAR APIs, tho, could you help us generate examples? ✪
Justin Richer: Yes, I think I could take concrete wild stabs based on what I know about VCs? ✪
<mprorock> the proposal run was "PROPOSAL: Implementations SHOULD support authorization delegation by using technologies such as GNAP and Authorization Capabilities." - i have no interest at this point in implementing gnap at this point, that proposal implies that i should implement that - so how is that a misread
... I think what people are worried about is not what I'm proposing
Manu Sporny: PRE-PROPOSAL: Implementations MUST support OAuth2 for the /credentials/verify endpoint. Implementations MAY support other authorization mechanisms for the /credentials/verify endpoint. ✪
Manu Sporny: Separating OAuth2 and RAR questions ✪
...with a new proposal
<mprorock> I am a big fan of separating these items