Is the 'txn' element required or optional

[Mark Haine]

It is not clear in the spec whether the txn element is required or optional. This should be made clear

[Dima Postnikov]

Is there any ecosystem that doesn’t require 'txn' claim? If it is a fundamental requirement for any identity assurance use case, perhaps it should be REQUIRED.

[Mark Haine]

I can imagine an implementation where txn is not required and the IDP is implicitly trusted and the expectation is any dispute is initiated by the end-user at the IDP so I think we should make it optional. I also think that from a tracking and data minimisation perspective it should be optional. Also because there is so much else in this spec that is optional then there will need to be specific profiles or detailed design documents needsd for implementations in any case.

[Mark Haine]

@Takahiko Kawasaki was unable to submit this comment himself…

“A certain customer in Japan is in the process of upgrading their system from Authlete 2.2 (supporting OIDC4IDA ID2) to Authlete 2.3 (supporting OIDC4IDA ID4). During the process, they encountered a problem where id_document was not accepted as a valid name of evidence. The root cause is that id_document has been deprecated as one of many breaking changes of OIDC4IDA. eKYC-IDA PR 152 has removed id_document from the JSON schema files that Authlete uses for validation of verified_claims.The right approach is to fix the problematic authorization request (by replacing id_document with document), but for business reasons, the client application cannot be updated soon, said the customer. Therefore, Authlete quickly implemented a mechanism to switch the set of JSON schema files for backward compatibility.From this experience, I can easily imagine that changing requirement of the txn claim from OPTIONAL to REQUIRED will cause another backward compatibility issue. It seems that the txn claim should remain optional.“

[Mark Haine]

Having looked more closely at the txn element and other elements in a similar part of the spec I suggest that it should not remain in this part of the spec and should eb moved into the definition of the verification element.

It seems to me that it may be useful as a key in the verified_claims element and so should be moved into that section.

[Mark Haine]

Incidental to the txn key as described in the documemnt there is also a txn key defined under evidence_ref and check_details, and a bunch of examples later in the document - we should probably put wording in to make sure these are not confused with each other

[Mark Haine]

## txn Claim

Strong identity verification typically requires the participants to keep an audit trail of the whole process.

The `txn` Claim as defined in [@!RFC8417] is used in the context of this extension to build audit trails across the parties involved in an OpenID Connect transaction.

If the OP issues a `txn`, it MUST maintain a corresponding audit trail, which at least consists of the following details:

* the transaction ID,
* the authentication method employed, and
* the transaction type (e.g., the set of Claims returned).

This transaction data MUST be stored as long as it is required to store transaction data for auditing purposes by the respective regulation.

The RP requests this Claim like any other Claim via the `claims` parameter or as part of a default Claim set identified by a scope value.

The `txn` value MUST allow an RP to obtain these transaction details if needed.

Note: The mechanism to obtain the transaction details from the OP and their format is out of scope of this specification.

‌

[Mark Haine]

PR 158 removed txn from the OpenID Connect for Identity Assurance draft but it was agreed that a separate draft be prepared to describe the txn claim more fully based on the text that was deleted from the IDA draft.

There were also comments in PR#159 that was declined that may be useful in the preparation of the future work on a txn focussed draft.

[Mark Haine]

Agreed that we would split the definition of txn out into a separate draft. - undecided whether an OpenID Foundation document or IETF

[Dima Postnikov]

George Fletcher pointed out that txn claim is already defined in Security Event Specification RFC8417 https://www.rfc-editor.org/rfc/rfc8417.txt :

   "txn" (Transaction Identifier) Claim
      An OPTIONAL string value that represents a unique transaction
      identifier.  In cases in which multiple related JWTs are issued,
      the transaction identifier claim can be used to correlate these
      related JWTs.  Note that this claim can be used in JWTs that are
      SETs and also in JWTs using non-SET profiles.

It looks likes it is also registered with IANA:

   o  Claim Name: "txn"
   o  Claim Description: Transaction Identifier
   o  Change Controller: IESG
   o  Specification Document(s): Section 2.2 of [RFC8417]

Might be a good idea to reference it in eKYC base specification as optional claim. The description seem to fit well our use case although we use it as a “Business event“, not a “Security event“..

Objections anyone?

[mark]

I have been lookin at this as part of some design work I am doing and a bit of re-wording is all that is needed around the txn key defined under evidence_ref and check_details.

[mark]

should we consider deleting verifier key as the definition already contains “is retained for backward compatibility“

[mark]

I don’t remember if there was a conscious decision to not have txn in the definition for electronic_signature evidence type

[Mark Haine]

addressed by PR#190

[Mark Haine]

potential duplication of time within the following evidence types - should we fix?

document.time duplicate of document.check_details.time?

electronic_record.time duplicate of electronic_record.check_details.time?

vouch.time duplicate of vouch.check_details.time?

‌

‌

[Mark Haine]

question around time is whether the proposal to delete time at the same level as check_details breaks any real implementations

‌

[Mark Haine]

Resolved by PR #190