Differences to the Information Model regarding DAT scope and audience

[spetrac]

I already issued this in the IDS-G-pre, but the topic was not discussed and the open points were not resolved, although they were serious concerns and researched well, so I want to reopen the issue here again. The original text of the issue will follow down below:

---

Hi there,

I am in the process of creating a DAPS client application and I am working on the client assertion part of it following the Dynamic Attribute Provisioning Service (DAPS) documentation. To produce some test results, I am using the omejdn-daps in a docker configuration. I already got it to work, but when deciding for a final vocabulary that is aligned to the information model and the json-ld context as suggested in this documentation, I come across some missmatches in the documentations and some issues in the information model as well, though I don't know where to address those. That makes it very difficult to find the correct attributes and default values.

The audience (aud) in the DAT-Request is described as "The audience of the token. This can limit the validity for certain connectors." Does this refer to the audience for the DAT-Request or is this a hint for the DAPS that I want an access token for this audience? I mean, the audience for the DAT-Request is obviously the requested DAPS. The description for the audience of the DAT is the same as for the DAT-Request and in the example we can find idsc:IDS_CONNECTORS_ALL as possible value. Searching in the information model reveals that such an individual does not exist. The file describing the audience shows that there is only one individual idsc:IDS_CONNECTOR_ATTRIBUTES_ALL. Its description states: "Every IDS Connector is in the intended audience for the DAT with this 'scope' property." Does that mean this audience individual, which is already the only one available, is not even intended for the audience claim of the DAT and should only be used for the scope? Looking further in the example shows that the scope could possibly be ids_connector_attributes which also does not exist and might actually also refer to idsc:IDS_CONNECTOR_ATTRIBUTES_ALL. By the way, the scope property is described in the model as "Currently, the scope is limited to 'Connector' but can be used for scoping purposes in the future. Scope is currently fixed to 'https://w3id.org/idsa/core/Connector'." - which does not align to the desciption of the scope in the DAPS document.

From my previous understanding this all does make little sense. The audience claim as of RFC 7519 identifies the recipients that the JWT is intended for. which means a IDS_CONNECTORS_ALL would make sense to identify all ids connectors (if it would exist). Maybe the idsc:ALL individual from the QueryScope could be fitting, although the wording is kind of confusing. The idsc:IDS_CONNECTOR_ATTRIBUTES_ALL could also be the right fit, although the description is missleading and the wording ATTRIBUTES_ALL is not intuitive at all.

The scope claim on the other hand as of IM/security/Token refers to the scope described in the subject claim of RFC 7519 which states: "The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique." Now this leads to a logical problem: The issuer of the DAT is the DAPS and the subject of the DAT, which is the combined SKI:AKI from the DAT-Requests subject and issuer claim, must be globally unique in the context of the DAPS anyway, because the subject claim of the DAT-Request is used to identify the certificate for the validation of the client assertion.

Following that thought, this could only mean that the logical subject for this DAT could be less than the whole connector identified by the SKI:AKI itself, but only a component of that connector, which could not be identified by an individual SKI. This would limit the usage for the requested DAT to a subset of components/actions the connector could use/perform. In that case, the identifier and the description of idsc:IDS_CONNECTOR_ATTRIBUTES_ALL are very missleading and should be more something like idsc:IDS_CONNECTOR_ALL_METHODS, which would enable every component of the connector to use this DAT, or idsc:IDS_CONNECTOR_ONLY_SELFDESCRIPTION, which would enable the connector to only get self descriptions of other connectors with this DAT. The description of the scope property, as referenced earlier, suggests the only currently supported value for the scope of ids:Connector, which I would indeed understand as: the whole connector can use this DAT.

To summarize everything and make it more clear:

• the claim values for DAT and DAT-Request are not aligned with the info model
• the wording and descriptions of info model properties and individuals, especially ids:scope and idsc:IDS_CONNECTOR_ATTRIBUTES_ALL, are missleading
• the explanations in the DAPS documentation lack description of purpose for some properties and options are not presented
• examples in the DAPS documentation are unrealistic and would not work in an actual implementation (e.g. looking at unpacked DAT-Request)

Besides those issues I could follow the documentation along and implement a working DAPS client for the omejdn-daps reference implementation pretty good, although I wish some properties and their purpose could be explained a little bit better, so one could implement a dependable solution.

---

Found another difference: The @type for the DAT-Request should be ids:DatRequestToken, but this also does not exist in the model. Searching in the JSON-LD context reveals that there is the class DatRequestPayload which is probably meant to be the type for the DAT-Request

---

Found another difference: The @type for the DAT as of its description should be ids:DatRequestToken, but this does not exist in the model. The @type for the DAT as of the example below should be ids:DatPayload, which does actually exist and might be the correct value. The JSON-LD context also shows a ids:DynamicAttributeToken but this would be the signed jwt I guess.