What is the scope of a signature?

[Tom Jones]

In the past a singer (issuer, OP) was attesting to all of the elements in the document signed. (subject to the terms of course). If signed “blobs” are included in a signed document, I propose that the the signer is taking responsibility for all of the attributes in the document that are not signed by others.

This issue came up wrt the mDL which is likely to be initiated by a MVD but include covid credentials from an IIS or even a private lab. I don’t believe the MVD is making any statement about the covid creds.

Note also that the expiry date becomes less absolute. As in the case of a passport, it has some extended validity for a year after expiry. Also a mDL my no longer work to authorize driving a car, but still allow you to buy alcohol. Composite docs will have expiry of different attributes at different times.

[Jeremie Miller]

On the matter of expiry, I believe that all digital representations of any physical identity documents must have two independent expiration values.

One is the expiration of the physical analog, representing the term upon which the issuer requires additional assurance for the scope of the identity binding itself.

The other is the expiration of the digital signature, intended to limit based on key management and software/infrastructure integrity.

It should be possible to have the digital expiration be valid after the physical analog’s if the signer implements that policy.

[Jeremie Miller]

If signed “blobs” are included in a signed document

My experience has been that trying to support any type of encapsulation of foreign cryptographic payloads is extremely dangerous. The ideal approach is to always deliver them alongside any cryptographic statements which can include hashes for verification.

The reason for this is it creates a weakness in implementations where it is too easy to perform your security evaluation and then move to processing logic. Encapsulation requires going back and forth between the two, whereas parallel/sibling cryptographic payloads allows the security checks to all be done once before moving to processing logic.

[Tom Jones]

sorry i mixed expiry in this - let's move that discussion elsewhere.

I am surprised at the push-back i am getting here and elsewhere about need for encapsulated, signed packets. I had thought we had general agreement on the need - but no matter, Why is an encapsulated, singed packet required? I will not address the programmer's problem, they need to live with difficult problems all the time. (My own preference is microservices.)

Use case - the relying party needs to know that identity proofing has been performed and that the user’s device has provided current proof-of-presence (pop), both at a high level of assurance. Clearly the identity proofing and pop are not performed at the same place. There is no reason for a relying party to expect that this is the case. But, the objection might be, surely an IdP (OP, whatever) can be built that acquires the pop and the id-proof and creates a single statement as to the IAL, AAL and even FAL levels of assurance. Yes, that is possible, and the normal flow up till now. If we want to be limited to that flow to make the RP programmers job easy, then that is an option. However, it gives the user little choice and little control of their own PII, and so is likely not to survive in a world of SSI and VC.

I hope that is sufficient evidence that encapsulated, signed packets will be required and we just have to live with them. Now, back to my proposal. Is it a valid approach?

[Jeremie Miller]

I apologize for being unclear in my concern. I completely support the use case 👍

I prefer for cryptographic references to be used instead of actual blob encapsulation. It’s purely a protocol formatting preference to minimize the complexity of the security processing logic.

It does not restrict the semantics of the relationships, it’s only about how they are packaged and transported.

I agree with your original premise that each signed body is only asserting the claims within it, and NOT the claims in other related/referenced/bound signed bodies which MUST be evaluated in their own context.

[Tom Jones]

i guess you are arguing for include-by-ref, rather than include-by-value. You will find more opinions about that than there are people in the room. Let’s just allow for both and get on with our work.

[Tom Jones]

https://bitbucket.org/openid/connect/issues/1171/creating-a-way-to-mandate-request-object

talks about “include-by-ref, rather than include-by-value”

[Tom Jones]

At the meeting of 5/20 it because clear that no one agreed to what the signature actually did apply. The problem seems to go back to a continuing confusion between attributes and claims. The NIST definition of attributes makes clear that these are not verified in IAL1, but are in higher assurance levels. So it seems that the signature means a different thing depending on:

1> Is the claim a user attribute?

2> Is the claim created by the OP?

3> is there anything in the token that is not category 1 or 2?

4> does the token assert it is for a high level of assurance (in which case the signature would be asserting something about some attributes)?

The following were not user attributes: start date and end date of the validity period.

The SUB is an interesting case as it is designed to be unique to the user and would be considered PII by the GDPR, but it is assigned by the OP (true even for the SIOP case) and so would be asserted by the OP.

(From SP 800-63a) A CSP that supports only IAL1 SHALL NOT validate and verify attributes.

1. The CSP MAY request zero or more self-asserted attributes from the applicant to support their service offering.
2. An IAL2 or IAL3 CSP SHOULD support RPs that only require IAL1, if the user consents.

I propose that this information be made clear in all new docs from OpenID.

‌

[Michael Jones]

As discussed on the 20-May-21 working group call, signing data integrity protects a set of claims intended to be communicated by the issuer. The trustworthiness or veracity of those claims is separate from the integrity protection that the signing accomplishes.

I believe we should close this issue on this basis, since the question asked has been answered.

[Tom Jones]

I guess you’re saying the scope of the signature is in the eye of the beholder. I was hoping for more clarity than that.

I wanted a trustworthy set of claims for xal2 and up. it seems that the only place that will be known is in the policies of the IdP. That also implies that the siop signature is not trustworthy since it is ipso facto self-certified.

[Michael Jones]

The scope of the signature is not in the eye of the beholder. It’s scope is to convey that the set of signed claims are being communicated by the issuer, with integrity-protection of them provided by the signature. No more - no less.

[Tom Jones]

If that is true then OIDC is not qualified to carry any binding between the human user at the device and the claims, ie proof-of-presence.

[Michael Jones]

OpenID Connect is qualified to carry claims of any kinds between OPs and RPs. Those claims may also reflect bindings between the OP, a human user, and the device, including proof-of-presence, but establishing those is the result of applying business processes (which are sometimes part of Trust Frameworks) as to how the OP obtains the claims.

Tom, we answered the question you asked, which is what the scope of the signature. If you want additional business processes, that’s great, but those go beyond what the signature does (although the results of them are integrity-protected by the signature).

[Tom Jones]

fine - i understand what you are saying, & I think i understand why you say it. I believe you will find it inadequate to make clear the binding between two sets (aggregated, presentation, whatever) of claims that are both contained in one token. We don’t need to continue this discussion now.

Authentication

Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity.

[Tom Jones]

I also ran into a discussion with Sam Smith as to the meaning of a signature. I used some of his thought to create this view of the meaning. https://tcwiki.azurewebsites.net/index.php?title=Digital_Signature

Still, I doubt any rational argument will change the view of technologists that they have the ability to change the meaning of words.

[Tom Jones]

Settled for now