[IDA] digest of external attachment is not always computable

[Takahiko Kawasaki]

IDA ID3 Section 5.1.2.2. External Attachments requires digest for each external attachment. However, it is not always possible to compute digest values at the time when an authorization server issues an ID token or returns a userinfo response which includes attachments. Content of attachments may be hosted on resource servers that are managed by other entities which is different from the entity that manages the authorization server. In this case, it is difficult, if not impossible, to compute digest values of the contents. A certain company is planning to implement an authorization server that supports IDA ID3 and they told us that the pattern actually exists, where evidence contents are hosted on resource servers of end-customers of the company.

I propose changing the requirement of the digest property from REQUIRED to OPTIONAL.

[Torsten Lodderstedt]

@Takahiko Kawasaki thanks for bringing this up.

Your proposal raises an interesting question: what is the purpose of the digest? We added it to ensure the RP can check whether the attachment provided via the respective URI is the same as … what? I assume a document shown to the user during consent or someplace else? So what is the security property we want to achieve?

[Kosuke Koiwai]

when used with signed idtoken/userinfo, digest can be used as an “evidence” that the file received is genuine.

[Vladimir Dzhuvinov]

The cryptographic digest binds the attachment to the ID token / UserInfo.

If the OP links to an attachment which content it cannot access (for technical or other reasons), but it can vouch for the attachment URL, why not make the attachment be a simple JSON or other document that contains the attachment URL? This will make it explicit to RPs that the OP sees the evidences as URLs and not in their content.

[Kai Lehmann]

The digests are used by the RP to verify the authenticity of the attachments as the digests are signed together with the ID Token. Having only the URL signed does not guarantee that the resource accessed via the URL is the correct evidence. The RP has to trust the OP that the attachment is the correct one as the RP would not be able to verify the integrity of the document itself. Now, @Takahiko Kawasaki mentioned that the attachments are hosted on entities which are not under the control of the OP (if I understood this correctly). How would the OP be able to vouch for the authenticity of the documents if they are not under their control? At one point or another, the OP (or the identification provider the OP has been using to gather the evidence) would need to have access to the documents at which time the digest values should be calculated and stored together with the extracted user information. After this, direct access to the attachments by the OP is not necessary anymore. Instead, the OP would simply reference the stored URL and digest value to the attachment in the evidence section and the RP can download the attachment and verify that it is in fact the one which has been used by the OP (or its identification provider) as proof. It would not be a correct approach if the OP would only store the URL for an evidence document and later - whenever the evidence data is to be provided inside of verified claims - read that document and calculate the digest. The document behind that URL could have been changed at this time already.

Furthermore, the URLs of the attachments may not necessarily be stable, but the digests are. For example, the RP can download the attachments and store them in their own evidence archive together with the ID token signed by the OP. The RP can then add meta info to that dataset to allow mapping of the URLs used in the ID Token to the URLs of the internal evidence archive. This allows the RP to access the attachments internally while maintaining the ability to verify the integrity based on the digests signed within the ID token.

[Vladimir Dzhuvinov]

I wondered if the situation Taka described is not a case for electronic_record in disguise.

Regarding URL → content stability, one way to guarantee this mapping within the URL itself is to include the digest as component (which clients can then verify).

‌

[Mark Haine]

Consider re-word to use SHOULD

[gffletch]

If we choose to move to using SHOULD instead of REQUIRED then we should add some text to the Security Considerations making it clear that external attachments that do NOT contain a hash must not be trusted as highly as those with an associated hash. It may be possible to swap the content of the external attachment if a hash is not provided.

[Takahiko Kawasaki]

Sorry, I didn’t know this thread had grown (it was pointed out in yesterday’s WG call).

I agree that the IdP should be able to compute digest values. Theoretically, yes, it should. My point was that actual deployments of IdP and resource servers are built with various technical components provided by different vendors, and the servers may be operated by different entities. If REQUIRED is critically necessary, it’s okay as a technical specification. But if there is room to loosen the requirement, deployment patterns can be flexible.

Personally, because I could confirm that the company would be able to compute digest values even in the case where resource servers are operated by different entities, the current requirement (REQUIRED) will not cause problems for now. So I can withdraw this proposal. But apart from it, it may be worth continuing discussion.

[Vladimir Dzhuvinov]

The SHOULD (the digest optionality) can end up being a major security downgrade for the integrity of attachments.

My feeling is there must be a better way to handle exceptions like the one Taka is dealing it. If the OP can compute a digest for the URL, but not for its content, then why not do just that. I explained my reasoning in a comment above. This makes it clearer and explicit what information the OP is capable of hashing, rather than dropping the hash altogether and saying the attachment then becomes less trusted.

[Vladimir Dzhuvinov]

Thanks Taka for your update, I saw it after posting my comment.

So let’s keep the REQUIRED for now. To reiterate, if an OP is not able to set an integrity protection for the attachment content, then for the bit that it can - the attachment URL.

‌

[Kai Lehmann]

Im not convinced that hashing the URL does help. The URL is already part of the JWT and thus its integrity is protected by the JWT signature. Furthermore, we would need to extend the protocol to tell the RP whether it was the URL or the actual content which was hashed.

[Vladimir Dzhuvinov]

Hi Kai,

My thought was to have such attachments be a simple JSON document like this:

‌

{
  "attachment_url": "https://scans.example.com/3194c417-862b-4383-8461-6afa16f2ecff",
  "note": "The OP doesn't guarantee the integrity of the document at the attachment URL"
}

‌

I.e. the attachment being a meta document. The digest remains, the protocol fundamentals are not changed, the RP knows what it’s getting.

[Kai Lehmann]

Understood, another layer of indirection. Not sure if we want to promote this kind of use. Not only would this allow an infinite number of indirections, but we may also need to specify the JSON schema for this as well.

[Vladimir Dzhuvinov]

To clarify, I wasn’t thinking of promoting that in the spec. Not at all.

If an OP chooses an approach like that the burden of speccing the JSON schema for the “attachment” is on it.

[Torsten Lodderstedt]

We discussed this issue in the call and came to the conclusion that we keep the digest value required for now. Taka agreed with with this conclusion.