question about verifying DID permissions in did-method

[michaelzhouyd]

Hi there,

Could you please help answer a question about verifying DID permissions in did-method?

In the seciont of 3.2.1 Verify Request Header of the document of "did:wba Method Specification(V0.1)", there is a discription of "Verify DID Permissions: Verify if the DID in the request has the permission to access the resources of the service. If not, the service returns".

My question is that what is based on for the service agent to grant resource permission to the client agent? if it is based on verifying the signed messsage by the pulic key from the client agent, it only proves that the request is from the entity who holds the private key conresponding to the public key.

If the client agent wants to get some special resource from the service agent, my understanding is that there must be some agreetment between the service agent and clients before the request in some kind of form which can be related to the client agent. But I don't know what it is and how to do the mapping in the current situation from your idea.

if the client agent wants to get the general resource open to everyone, the authentication by DID may be not necessary even from security perspective, because the server client can guarantee the connection security by the mechanism simliar to https and may not care who do the reqest for general resource.

thanks

[chgaowei]

Thank you for your question.

At present, our protocol has not yet implemented the authorization part — for example, in a scenario where Agent A wants to access the resources of Agent B, and Agent B authorizes A through a protocol.

In our current design, we use a case such as hotel booking:
Agent A uses its DID to request hotel-related data from Agent B (the hotel’s agent). Since hotels generally want their services to be more visible, Agent B usually will not reject A’s request — unless B detects that A is a bot or a crawler from a search company.

For cases that require authorization, one simple approach is to manually configure Agent A’s DID inside Agent B. This is one method, but there should be better approaches in the future.

Our use of DIDs is not designed primarily from a security perspective, but rather from an identity perspective. B needs to know who is requesting its data, and it can then set up blacklists or whitelists. All of this requires knowing the requester’s identity — especially in scenarios such as hotel booking.

Of course, for certain public services, such as a public website, identity verification can be skipped. This is ultimately up to the developers of Agent B.

I’m not sure if I’ve expressed it clearly — I’d be glad to continue the discussion.

@michaelzhouyd

[chgaowei]

The interaction between agents and websites differs in one important way:
Websites cannot require all users to log in, as this would raise the barrier to use — since it needs people to log in manually.

However, agents can require other agents to include an identity when making requests, without significantly raising the barrier to use. This is because the counterpart is also an agent, and it connects through a protocol.

@michaelzhouyd

if you have wechat id, can add me：flow10240