• Start recording
• Welcome & antitrust notice
• Introduction of new members
• Agenda review

• Antitrust Policy Notice: Attendees are reminded to adhere to the meeting agenda and not participate in activities prohibited under antitrust and competition laws. Only members of ToIP who have signed the necessary agreements are permitted to participate in this activity beyond an observer role.
• New Members:

News or events of interest to members:

• IIW Super early bird ~10 tickets

Reports

• Recovery Rotation rules
  • see recording starting: 34 minutes.
• Logging in with ACDC. During the dev call the Signify Browser Extension was shown. We discussed logging in with AID and/or ACDC credentials.
  • Signed with AID for authentication
    • In the extension the headers are signed
  • Submitted credentials for authorization.
    • If an AID is whitelisted, anything that AID signs is authentic. Then credentials are providing authorization
      
      • Signed credential
      • Use the IPEX protocol to present credentials
        • Signing the presentation to prevent a replay attack using something like a date-time stamp
        • Admit message provides proof of receipt. 
  • Similarly, connecting passkey with identity. Future log in is signed using the passkey.
    • A vLEI credential can provide the identity assurance... This AID comes from a company and we have a relationship, so they are 'pre-registered'.
    •  Signing only show control of a private key, for more context we need identity information like credentials.
  • In the EBA PoC a signed report is being submitted. This is separate from access control, which has timeliness issues.
    • Banks are whitelisted and manage their delegation via the Document Submitter credential (bearer token)
      • EBA is not the identity service provider
        • EBA trusts the banks are managing the issuance of the Document Submitter ECR credential. EBA verifies the validity of the credential at the time of submission and the signature on the report.
      • If reports are versioned that provides replay attack protection
        • It doesn't hurt to sign the presentation, it is an additional layer of security but possibly over-complex for the use case.
      • Keeping the semantics of the role credential narrow is important for avoiding BOLA attacks. Signing the presentation of the credential is advised in use cases where the semantics vary.
  • Two types of interactions:
    • Setup/Registration interaction, new AID and authorization to establish access control. You present a vLEI credential. You don't want that captured and misused. Narrowing the scope to a certain role (like Document Submitter) is a pre-registration via delegatable authority.
      • Credential is like a bearer token. Does it matter if the credential was delivered by the issuee? The token is proof of the authorization, but does the delivery require the issuee signature? Depends on the context. If it is an idempotent process resubmission has no effect.
    • Access controlled actions like submitting the report. Replay attacks are less of a concern, other than DDoS attack using resubmissions. If you already have that report then load balancer needs a mechanism to drop repeated requests.

• Review decisions/action items
• Planning for next meeting