Is the 'txn' element required or optional
It is not clear in the spec whether the txn element is required or optional. This should be made clear
Comments (22)
-
-
reporter 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. -
reporter - changed status to open
-
reporter - changed milestone to IDA Final
-
assigned issue to
-
reporter @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 ofevidence
. The root cause is thatid_document
has been deprecated as one of many breaking changes of OIDC4IDA. eKYC-IDA PR 152 has removedid_document
from the JSON schema files that Authlete uses for validation ofverified_claims
.The right approach is to fix the problematic authorization request (by replacingid_document
withdocument
), 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 thetxn
claim from OPTIONAL to REQUIRED will cause another backward compatibility issue. It seems that thetxn
claim should remain optional.“ -
reporter 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. -
reporter Incidental to the
txn
key as described in the documemnt there is also atxn
key defined underevidence_ref
andcheck_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 -
reporter ## 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.
-
reporter PR 158 removed
txn
from the OpenID Connect for Identity Assurance draft but it was agreed that a separate draft be prepared to describe thetxn
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. -
reporter - removed component
- removed milestone
-
reporter -
assigned issue to
-
assigned issue to
-
reporter Agreed that we would split the definition of
txn
out into a separate draft. - undecided whether an OpenID Foundation document or IETF -
reporter -
assigned issue to
-
assigned issue to
-
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?
-
reporter -
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 underevidence_ref
andcheck_details
. -
should we consider deleting
verifier
key as the definition already contains “is retained for backward compatibility
“ -
I don’t remember if there was a conscious decision to not have
txn
in the definition forelectronic_signature
evidence type -
reporter addressed by PR#190
-
reporter potential duplication of
time
within the following evidence types - should we fix?document.time
duplicate ofdocument.check_details.time
?electronic_record.time
duplicate ofelectronic_record.check_details.time
?vouch.time
duplicate ofvouch.check_details.time
?
-
reporter question around time is whether the proposal to delete
time
at the same level ascheck_details
breaks any real implementations
-
reporter - changed status to resolved
Resolved by PR #190
- Log in to comment
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.