Skip to content

Clarify the human-authorization model after did:wba v1.1 #90

Description

@Math1987

Hi — I reviewed the current ANP specifications and AgentConnect before proposing any change, and I would like to clarify the intended human-authorization model.

Issue #14 documented the earlier approach in which humanAuthorization was a dedicated DID verification relationship/key.

The current documents now appear to describe a different layering:

  • ANP-03 v1.1 says that DID Documents no longer define humanAuthorization. Human confirmation belongs to an upper-layer authorization policy, and the document gives authorizationLevel: user-presence-required as an example.
  • ANP-07 defines the interface-level boolean humanAuthorization.
  • Draft ANP-06 uses requiresHumanAuthorization as a capability or negotiation constraint and explicitly states that it does not mean authorization has been completed.
  • The technical white paper still describes humanAuthorization as a dedicated DID verification method/key that must sign high-risk requests.

Could you confirm whether the intended model is:

  1. did:wba authentication proves the caller/request identity;
  2. ANP-07 humanAuthorization declares that an interface requires human approval;
  3. ANP-06 requiresHumanAuthorization expresses that requirement during capability discovery or negotiation;
  4. completion and verification of the actual approval are left to the upper-layer business protocol and local authorization policy?

It would also be helpful to clarify whether authorizationLevel in ANP-03 is only an illustrative example, or whether it is intended to become an Agent Description field alongside or instead of humanAuthorization.

If this interpretation is correct, would a small documentation-only PR be welcome to:

  • align the technical white paper with ANP-03 v1.1;
  • add a short cross-reference between ANP-03, ANP-07, and ANP-06;
  • explain the distinction between declaration, negotiation, and actual approval;
  • update the relevant English and Chinese documentation together, so that the terminology and authorization model remain clear and consistent across both versions?

I would keep this purely editorial, without proposing a wire-format change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions