dhh1128
commented
1 year ago Two thumbs up from me. I love this idea!
On Mon, May 15, 2023, 10:28 PM Samuel Smith @.***> wrote:
KERI AIDs support delegation to other AIDs. The delegator AID can have delegate or delegatee AIDS. The Delegate inception event is special in that it indicates a Delegator AID and the Delegator AID must anchor a seal in its KEL of the Delegate's inception event in order for a validator to accept the delegate's KEL as valid.
Because this delegate and delegator relationship is cryptographically verifiable. Its a strong binding. A validator could in its business logic decide to accept signed presentations of a credential where the presenter who is signing the presentation is not the the controller of the named issuee AID in the credential but the controller of a delegated AID of the named issuee AID (where the Issuee is the Delegator).
This presentatin rule could also be added to the ecosystem governance framework for a given type of credential
From an issuer standpoint. we can add a field in the schema or the rules section for that credential by which the issuer indicates that presentation by delegates of Issuees is allowed or not. This needs to be defined.
But presentation by delegatees provides a novel privacy preserving mechanism since the Issuer has no knowledge of the delegated AIDs and a Given issuee could create a bespoke delegated AID on the fly for the purpose of a given presentation of the credential. This would allow OOB disclosure and presentation by a delegate where the actual credential is the private compact version.
— Reply to this email directly, view it on GitHub https://github.com/trustoverip/tswg-acdc-specification/issues/77, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ3JCBADI63OVY2FCWHXRLXGKGVNANCNFSM6AAAAAAYCWD4OA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
KERI AIDs support delegation to other AIDs. The delegator AID can have delegate or delegatee AIDS. The Delegate inception event is special in that it indicates a Delegator AID and the Delegator AID must anchor a seal in its KEL of the Delegate's inception event in order for a validator to accept the delegate's KEL as valid.
Because this delegate and delegator relationship is cryptographically verifiable. Its a strong binding. A validator could in its business logic decide to accept signed presentations of a credential where the presenter who is signing the presentation is not the the controller of the named issuee AID in the credential but the controller of a delegated AID of the named issuee AID (where the Issuee is the Delegator).
This presentatin rule could also be added to the ecosystem governance framework for a given type of credential
From an issuer standpoint. we can add a field in the schema or the rules section for that credential by which the issuer indicates that presentation by delegates of Issuees is allowed or not. This needs to be defined.
But presentation by delegatees provides both a novel horizontal signing scaling mechanism and a novel privacy preserving mechanism. In the former case the presentation infrastracture can be horizontally scaled by delegates each with their own signing infrastructure. IN the latter case the Issuer and Third parties could have no knowledge of the delegated AIDs from the original issuance and/or revocation registry. A Given issuee could create a bespoke delegated AID on the fly for the purpose of a given presentation of the credential. This would allow OOB disclosure and presentation by a delegate where the actual credential is the private compact version. This would allow a different form of contextualization of presentations that complements or replaces the bulk -issued mechanism currently in the ACDC specification.