WIP First cut of the AIP 2.0 list of RFC versions to be included #579

swcurran · 2021-01-06T02:25:12Z

Per discussions in recent Aries WG calls, this PR lists the RFCs to be included in the next AIP, pinned at the latest commit in the repo. Flagged in the PR are the new RFCs added, and those that are still being discussed. Included are the goals that we used for including RFCs. Still to do:

finalize the "Under Consideration"
review the RFCs that have been included and are not "Accepted" to move them forward.
update the "Test Suite" section -- what to put in there.
Add any narrative that might (or might not) be needed about the AIP. I kind of feel that the RFCs/Versions speak for themselves and by simply being in the AIP, the rationale is implied.

And of course, there is the merging of the PR, and then the merging of a PR to make the AIP v2.0 "Accepted".

Signed-off-by: Stephen Curran <swcurran@gmail.com>

llorllale · 2021-01-11T15:01:21Z

concepts/0302-aries-interop-profile/README.md

+
+- From AIP 1.0: Aries Agents must be able to establish connections, exchange credentials and complete a connection-less proof-request/proof transaction.
+- Aries agents must be able to reuse connections.
+  - RFCs 0434, 0023, 0519, 0360


0360

I submitted a proposal to move away from did:key. A primary motivator there is to achieve better cryptographic agility with the ultimate goal of supporting NIST curves.

Supporting NIST curves is very important to us.

Are you going to present on this on Wednesday? This was up in the air when we adjourned before the holidays and you were investigating.

@swcurran I can lead a chat in wednesday's call. @dhh1128 is also interested.

concepts/0302-aries-interop-profile/README.md

Signed-off-by: Stephen Curran <swcurran@gmail.com>

llorllale · 2021-01-19T22:56:46Z

We need a common way to ask for credentials and proofs. We should add RFCs 0510 and 0511 for this purpose (both propose using DIF Credential Manifest and Presentation-Exchange).

llorllale · 2021-01-19T23:00:31Z

We also need a way to separate keys based on their purpose (key agreement vs authentication), and we also need to support standard NIST curves/algorithms together with their standardized JOSE envelopes. I propose we add RFC 0577 for this.

dhh1128 · 2021-01-19T23:04:50Z

We should add RFCs 0510 and 0511 for this purpose (both propose using DIF Credential Manifest and Presentation-Exchange).

I like the Presentation Exchange work quite a lot. However, I don't think it's stable enough to base this AIP on. I think we will have to do that in the next one.

I do not feel the same way about the Credential Manifest. The problem for me is that it's using a data format to do the job of a protocol. I want to discuss more.

llorllale · 2021-01-20T20:16:59Z

concepts/0302-aries-interop-profile/README.md

+&nbsp; | Format: BBS+ Signatures | :question: **Under Consideration**
+Feature | [0454-present-proof-v2](https://github.com/hyperledger/aries-rfcs/tree/be4ad0a6fb2823bb1fc109364c96f077d5d8dffa/features/0454-present-proof-v2) | AIP V1.0, **Update to V2**
+&nbsp; | Format: Indy AnonCreds | AIP V1.0, Updated
+&nbsp; | Format: DIF Presentation Exchange | :question: **Under Consideration**


llorllale · 2021-01-28T22:51:29Z

@dhh1128

We should add RFCs 0510 and 0511 for this purpose (both propose using DIF Credential Manifest and Presentation-Exchange).

I like the Presentation Exchange work quite a lot. However, I don't think it's stable enough to base this AIP on. I think we will have to do that in the next one.

I do not feel the same way about the Credential Manifest. The problem for me is that it's using a data format to do the job of a protocol. I want to discuss more.

After yesterday's call we are all (including you) converging on presentation exchange as a proof request format - good
I think it is Credential Manifest that may not be stable enough yet. Spec work resumed today and the concepts and use cases are being drawn up again

Do you have a proposal for an interoperable credential request format?

dhh1128 · 2021-01-29T22:04:25Z

Do you have a proposal for an interoperable credential request format?

Yes. My proposal would be to rip out of credential manifest everything that isn't about describing the data of the credential to be issued. No asking the potential holder for data; no description of the issuer; no description of how the credential gets rendered in a UI. All of those things are poison pills to me, but if we could simplify the credential manifest to just what you described -- make it truly a "credential request format", then I would support it.

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Subtarget proposal

…added RFCs for credential format subtargets Signed-off-by: Stephen Curran <swcurran@gmail.com>

llorllale · 2021-03-12T02:01:29Z

@swcurran @dhh1128

did:peer is not on this list. What do we need to make that happen?

Can we agree on method 1?

dhh1128 · 2021-03-12T20:49:19Z

Can we agree on method 1?

I don't know who's got support for that method, and whether the support is for static mode only, or static + dynamic. Dynamic support for method 1 would require people to implement Aries RFC 0030. I think very few impls have tackled that, and I think that protocol is in need of updating.

Bottom line: I'd be happy to see it adopted, but I think it's a matter for the whole community to weigh in on, so I think we should put it to a vote on both email and a call.

Method 0 would be trivial for anyone who already supports did:key (seriously; it's just modifying a did:key impl to recognize the prefilx did:peer:0). Method 1 in static mode is slightly harder, but within impl reach for anyone who can spend a day coding. It's only when you get to Method 1 in dynamic mode that it gets more expensive to support.

swcurran · 2021-03-12T20:58:12Z

@andrewwhitehead -- can you please weigh in on this when you get a chance? Thanks!

llorllale · 2021-03-15T15:16:32Z

@swcurran @dhh1128 @andrewwhitehead on adopting did:peer: #611

…are to be in AIP 2.0 Signed-off-by: Stephen Curran <swcurran@gmail.com>

llorllale · 2021-03-23T15:09:49Z

I am concerned that we do not have RFC0348 - Transition Message Type to HTTPs in the core section of AIP 2.0.

dhh1128 · 2021-03-23T15:35:49Z

I am concerned that we do not have RFC0348 - Transition Message Type to HTTPs in the core section of AIP 2.0.

+1

swcurran · 2021-03-23T15:44:56Z

I'll add it in. It should be fully executed by now.

@llorllale -- we are adding a config to the AATest Harness so that on startup a test agent knows what AIP they are using, so that we can have intelligent defaults for AIP 2.0 and eliminate some of the need for backward compatibility like this.

…ph on encryption envelope to AIP itself Signed-off-by: Stephen Curran <swcurran@gmail.com>

dhh1128 · 2021-04-09T17:49:01Z

concepts/0302-aries-interop-profile/README.md


 #### DIDCOMMV2PREP: DIDComm v2 Prep
 RFC Type | RFC/Link to RFC Version | Note
 --- | --- | ---
-Feature | [0334-jwe-envelope](https://github.com/hyperledger/aries-rfcs/tree/9363159d517afa3c17a79b5d8394e933c652de84/features/0334-jwe-envelope) | :question: **Under Consideration**
-Feature | [0587-encryption-envelope-v2](https://github.com/hyperledger/aries-rfcs/tree/9363159d517afa3c17a79b5d8394e933c652de84/features/0587-encryption-envelope-v2) | :new
+Feature | [0587-encryption-envelope-v2](https://github.com/hyperledger/aries-rfcs/tree/b982c24b9083dd5dddff6343dbf534cd1cfe36a6/features/0587-encryption-envelope-v2) | :new:<br>See envelope note below



I'm not sure if this belongs under DIDComm v2 Prep or deserves its own section, but the formalization of did:peer support in RFC 627 may now be worthy of mention?

Thanks, Daniel -- I'll get that added.

…IDs RFC Signed-off-by: Stephen Curran <swcurran@gmail.com>

Signed-off-by: Stephen Curran <swcurran@gmail.com>

troyronda · 2021-04-21T13:58:13Z

concepts/0302-aries-interop-profile/README.md

+
+AIP 2.0 contains two RFCs that reference envelopes 0019-encryption-envelope and 0587-encryption-envelope-v2 (links above).
+The important feature that Aries implementers should understand to differentiate which envelope format can or is being used by an agent is the
+`accept` element of the DIDComm service endpoint. If the `accept` element is not present in the agents service endpoint, the


@swcurran

accept element of the DIDComm service endpoint

and the out-of-band message

…ormat-agnostic revocation additions; update to latest commit Signed-off-by: Stephen Curran <swcurran@gmail.com>

Signed-off-by: Stephen Curran <swcurran@gmail.com>

…argets. Adding 0593 to BBS+ Signed-off-by: Stephen Curran <swcurran@gmail.com>

troyronda · 2021-05-26T14:29:42Z

concepts/0302-aries-interop-profile/README.md

+Feature | [0454-present-proof-v2](https://github.com/hyperledger/aries-rfcs/tree/d50fe1e38c9720344123146c31fbf7ad8e78b345/features/0454-present-proof-v2) | Update to V2 Protocol
+Feature | [0557-discover-features-v2](https://github.com/hyperledger/aries-rfcs/tree/d50fe1e38c9720344123146c31fbf7ad8e78b345/features/0557-discover-features-v2) | :new:
+Feature | [0627-static-peer-dids](https://github.com/hyperledger/aries-rfcs/tree/d50fe1e38c9720344123146c31fbf7ad8e78b345/features/0627-static-peer-dids)  | :new:
+


What about RFC092: transport return route? @swcurran @TelegramSam

Signed-off-by: Stephen Curran <swcurran@gmail.com>

swcurran

Approved by a unanimous vote at the Aries WG B Call, 2021.05.26.

Requests applied in the final update:

Added RFC 0092 to the Mediator Coordination sub-target
Updated the links to the RFC versions to the latest commit in the repo
Added a link to each RFC in both AIP 1 and 2 to show the diffs between the versions

Merge it @TelegramSam !

TelegramSam

Updates match requested in WG meeting

WIP First cut of the AIP 2.0 list of RFC versions to be included

597c539

Signed-off-by: Stephen Curran <swcurran@gmail.com>

swcurran added the WIP Work in Progress - Don't Merge label Jan 6, 2021

llorllale reviewed Jan 11, 2021

View reviewed changes

concepts/0302-aries-interop-profile/README.md Outdated Show resolved Hide resolved

Fixed typo around the file and mime types -- concept vs. feature

22412b9

Signed-off-by: Stephen Curran <swcurran@gmail.com>

llorllale reviewed Jan 20, 2021

View reviewed changes

TelegramSam and others added 5 commits February 2, 2021 16:56

Subtarget proposal

0d5ce50

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Updates to base mechanism language per WG meeting

961929d

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Updates made in WG meeting

9dc443c

Signed-off-by: Sam Curren <telegramsam@gmail.com>

Merge pull request #6 from TelegramSam/AIPv2

d80d9b8

Subtarget proposal

Removed Credential Manifest sub-target, added placeholders for to be …

fdf3d3e

…added RFCs for credential format subtargets Signed-off-by: Stephen Curran <swcurran@gmail.com>

swcurran added the AIP 2.0 Issues and PRs related to AIP 2.0 label Mar 14, 2021

llorllale mentioned this pull request Mar 15, 2021

AIP 2.0: support for the did:peer method #611

Closed

Updating the commit ID for all RFCs in AIP 2.0, adding new RFCs that …

a9d5e3f

…are to be in AIP 2.0 Signed-off-by: Stephen Curran <swcurran@gmail.com>

llorllale mentioned this pull request Mar 23, 2021

fix: fixes for didexchange interop with aca-py hyperledger-archives/aries-framework-go#2655

Merged

Update commit on RFC links. Adjust targets, removing 334. Add paragra…

98be524

…ph on encryption envelope to AIP itself Signed-off-by: Stephen Curran <swcurran@gmail.com>

dhh1128 reviewed Apr 9, 2021

View reviewed changes

Informational note on Message Types; ordered lists; Added 0627 Peer D…

52b16a9

…IDs RFC Signed-off-by: Stephen Curran <swcurran@gmail.com>

Typos fixed, link to in progress BBS+ RFC

88351b6

Signed-off-by: Stephen Curran <swcurran@gmail.com>

troyronda reviewed Apr 21, 2021

View reviewed changes

swcurran added 5 commits April 27, 2021 08:46

Add mention of OOB on envelope; remove Indy revocation from list of f…

765031b

…ormat-agnostic revocation additions; update to latest commit Signed-off-by: Stephen Curran <swcurran@gmail.com>

Merge branch 'master' into AIPv2

4e008fb

Update to latest commit; link to PR for BBS+ Credentials

9b7b3a8

Signed-off-by: Stephen Curran <swcurran@gmail.com>

Remove subtarget DIF PE -- it is part of the JSON-LD and BBS+ VC subt…

3ca3e28

…argets. Adding 0593 to BBS+ Signed-off-by: Stephen Curran <swcurran@gmail.com>

Merge branch 'master' into AIPv2

1f5f168

troyronda reviewed May 26, 2021

View reviewed changes

swcurran added 6 commits May 26, 2021 13:55

Add RFC 0092 Transport Return Route to Mediator Coordination sub-target

455d175

Signed-off-by: Stephen Curran <swcurran@gmail.com>

Merge branch 'master' into AIPv2

0c287cb

Merge branch 'master' into AIPv2

1747423

Change AIP 2.0 links to the latest commit

0d5e2ea

Signed-off-by: Stephen Curran <swcurran@gmail.com>

Merge remote-tracking branch 'origin/AIPv2' into AIPv2

7822496

Added links to diffs of RFCs updated from AIP 1 to AIP 2

fad5f2d

Signed-off-by: Stephen Curran <swcurran@gmail.com>

swcurran commented May 27, 2021

View reviewed changes

TelegramSam approved these changes May 27, 2021

View reviewed changes

TelegramSam merged commit 41d27af into hyperledger:master May 27, 2021

swcurran deleted the AIPv2 branch May 27, 2021 18:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP First cut of the AIP 2.0 list of RFC versions to be included #579

WIP First cut of the AIP 2.0 list of RFC versions to be included #579

swcurran commented Jan 6, 2021 •

edited

Loading

llorllale Jan 11, 2021

swcurran Jan 11, 2021

llorllale Jan 11, 2021

llorllale commented Jan 19, 2021

llorllale commented Jan 19, 2021

dhh1128 commented Jan 19, 2021

llorllale Jan 20, 2021 •

edited

Loading

llorllale commented Jan 28, 2021

dhh1128 commented Jan 29, 2021

llorllale commented Mar 12, 2021

dhh1128 commented Mar 12, 2021

swcurran commented Mar 12, 2021

llorllale commented Mar 15, 2021

llorllale commented Mar 23, 2021

dhh1128 commented Mar 23, 2021

swcurran commented Mar 23, 2021

dhh1128 Apr 9, 2021

swcurran Apr 9, 2021

troyronda Apr 21, 2021

troyronda May 26, 2021

swcurran left a comment

TelegramSam left a comment

WIP First cut of the AIP 2.0 list of RFC versions to be included #579

WIP First cut of the AIP 2.0 list of RFC versions to be included #579

Conversation

swcurran commented Jan 6, 2021 • edited Loading

llorllale Jan 11, 2021

Choose a reason for hiding this comment

swcurran Jan 11, 2021

Choose a reason for hiding this comment

llorllale Jan 11, 2021

Choose a reason for hiding this comment

llorllale commented Jan 19, 2021

llorllale commented Jan 19, 2021

dhh1128 commented Jan 19, 2021

llorllale Jan 20, 2021 • edited Loading

Choose a reason for hiding this comment

llorllale commented Jan 28, 2021

dhh1128 commented Jan 29, 2021

llorllale commented Mar 12, 2021

dhh1128 commented Mar 12, 2021

swcurran commented Mar 12, 2021

llorllale commented Mar 15, 2021

llorllale commented Mar 23, 2021

dhh1128 commented Mar 23, 2021

swcurran commented Mar 23, 2021

dhh1128 Apr 9, 2021

Choose a reason for hiding this comment

swcurran Apr 9, 2021

Choose a reason for hiding this comment

troyronda Apr 21, 2021

Choose a reason for hiding this comment

troyronda May 26, 2021

Choose a reason for hiding this comment

swcurran left a comment

Choose a reason for hiding this comment

TelegramSam left a comment

Choose a reason for hiding this comment

swcurran commented Jan 6, 2021 •

edited

Loading

llorllale Jan 20, 2021 •

edited

Loading