Normative version inconsistency for SD-JWT VC in 1.0 final by Sakurann · Pull Request #726 · openid/OpenID4VP

Sakurann · 2026-04-26T20:41:59Z

fixes #659 by changing typo in sd-jwt-vc version

c2bo · 2026-05-01T04:15:52Z

We need to touch that part anyway for 1.1 I believe (and check versions / remove some entries if there were no breaking changes)? Should this change be only scoped for 1.0 for the time being and we do a pass of the non-final specs part for 1.1 before final?

brentzundel · 2026-05-07T15:43:26Z

Discussed in call. We may need to update to 16, but only after making sure there aren't normative inconsistencies.
There is also an SD-JWT reference that need avaluation.

jogu

There's still an inconsistency as the normative references section now references draft 16. We need to update the normative references to be draft 10, unless there's a later draft that has no normative changes in which change we can update both places to that later version.

brentzundel · 2026-05-14T15:17:06Z

@Sakurann can you respond to the concerns raised by @jogu

Sakurann · 2026-05-15T16:45:35Z

Does @jogu 's concern only applies to the following sentence and section 2 vs 4? I don't understand the concern. is it still there if now the PR points to -16 and not -10?

A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

Sakurann · 2026-05-15T16:48:03Z

We need to touch that part anyway for 1.1 I believe (and check versions / remove some entries if there were no breaking changes)? Should this change be only scoped for 1.0 for the time being and we do a pass of the non-final specs part for 1.1 before final?

@c2bo do you see any problems with merging this PR now and we can revisit 1.1 before publication again

c2bo · 2026-05-15T16:55:36Z

We need to touch that part anyway for 1.1 I believe (and check versions / remove some entries if there were no breaking changes)? Should this change be only scoped for 1.0 for the time being and we do a pass of the non-final specs part for 1.1 before final?

@c2bo do you see any problems with merging this PR now and we can revisit 1.1 before publication again

fine by me and I believe Brent opened a new issue for that

awoie · 2026-05-27T13:13:33Z

 ##### Step 1: SD-JWT VC Processing

- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.
+- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.


Suggested change

- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2.4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

I agree that section 2.4 is the better reference. Section 2.4 also references the validation rules in section 2.5, so scoping it down like this makes it easier to find the rules without being too specific.

awoie · 2026-05-27T13:13:45Z

 ##### Step 1: SD-JWT VC Processing

- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.
+- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.


Suggested change

- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2.4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

awoie

thanks. we should use 2.4 instead of 2.

paulbastian · 2026-06-04T15:15:29Z

@javereec @fkj volunteering to review this PR

jogu · 2026-06-10T08:46:07Z

 * SIOPv2 draft -13 [@!SIOPv2]
 * Selective Disclosure for JWTs (SD-JWT) draft -22 [@!I-D.ietf-oauth-selective-disclosure-jwt]
-* SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -09 [@!I-D.ietf-oauth-sd-jwt-vc]
+* SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -16 [@!I-D.ietf-oauth-sd-jwt-vc]


Draft 16 contains at least one breaking change ( https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-16.html#name-document-history ):

Change lang to locale. While lang is more accurate, locale is what has traditionally been used in OpenID Connect and later related specs.

so I don't think we can just update to -16, unless people can think of language we can add that could explain this as not really being a breaking change.

There may be other breaking changes too, I didn't review the full history.

The alternative is to figure out how to make the normative references section of the draft refer to draft 10 (or the latest version that doesn't contain breaking changes). I don't know how we get mmarkdown/xml2rfc to reference a specific IETF draft rather than the latest one - probably we would need to create a manual reference instead of relying on the automatic [@!I-D.ietf-oauth-sd-jwt-vc] syntax.

javereec · 2026-07-02T12:53:54Z

Below are some notable differences between draft 10 and draft 16 of the SD-JWT VC spec that could potentially present an issue.

description	draft 10	draft 16
`vct#integrity` claim	Not part of "Registered JWT Claims"	Part of "Registered JWT Claims". Because if it, this must always be disclosed.
`status` claim constraint	No constraint on content format	Addition of "the associated Status List Token MUST be in JWT format" in section 2.2.2.2
Binary data encoding in claims	No requirement	Added requirement that: "Binary data in claims SHOULD be encoded as data URIs as defined in [RFC2397]" in section 2.2.2.3
Display data language tag property rename	Uses `lang` in section 8	Uses `locale` in section 4.5
SVG rendering method key change	Uses `svg_template` in section 8.1.2	Uses `svg_templates` in section 4.5.1.2
`vct` type metadata required	Not mentioned in type metadata in section 6.2	Mentioned and required in Type metadata in section 4.2
`schema` and `schema_uri` removed from type metadata	Mentioned in type metadata in section 6.2, but optional	Removed entirely from type metadata in section 4.2.
Type metadata glue documents (`vctm`) removed	Present	Removed
Introduction of `mandatory` claim in claim metadata	Not present	New `mandatory` boolean property. The claim itself is optional
Verification step when schema is present in type metadata removed	Contains "If a schema is provided in the Type Metadata, a recipient MUST validate the schema as defined in Section 6.5." in section 3.4	Verification step is removed in section 2.4

awoie · 2026-07-03T11:39:49Z

thanks. we should use 2.4 instead of 2.

I will also note that ETSI references -13. Because SD-JWT VC is probably most relevant for EUDI, and EUDI implementers will need to use -13, we should probably also use -13, or update to -16/-17 (next week) already. Between -13 and -16/-17 there shouldn't be any breaking changes.

brentzundel · 2026-07-16T15:37:37Z

After discussion in the WG today, we don't like it, but we should point to the latest version of SD-JWT VC and move forward.
Mid to long term there should probably be a registry.

jogu · 2026-08-10T09:23:53Z

After discussion in the WG today, we don't like it, but we should point to the latest version of SD-JWT VC and move forward.

Relevant minutes for references: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20260713/001320.html

The WG can't just decide "we're going to make breaking changes in an errata".

As I mentioned here #726 (comment) we really need to explain and justify why we're making a breaking change in an errata update (including making clear what behaviour we expect implementations with/without the errata update to have), and some of the explanation is likely to be guidance to implementers/ecosystems that needs to go into the specification text.

Mid to long term there should probably be a registry.

Can you expand on this point please? A registry of what? [Actually I think that question is answered by the minutes - I don't think a registry solves any of this problem - I believe it's a registry of credential format identifiers like dc+sd-jwt etc - but the registry still has to stay 'dc+sd-jwt' means "SD-JWT VC draft 18" and can't change the meaning of that value ever.)

brentzundel · 2026-08-13T15:49:51Z

Discussion in the group today: perhaps a breaking change in this circumstance might be necessary, and allowable under the need to address errata. If we go down this route, we need to be very explicit about the changes.
There seemed to be general support for this approach.
@Sakurann can you update this PR?

Sakurann · 2026-08-31T12:34:47Z

WG discussion (chair hat on)

multiple options:

option 1: use the same sd-jwt format identifier but update the version -10 to -16/final
- add a text saying that if the wallet does not know the version of sd-jwt vc, return it. many wallets do not know the version of the sd-jwt vc they hold. recommend final ver but not mandate.
option 2: define format identifier per sd-jwt vc version (potentially a registry)
option 3: define request parameter that allows verifier to specify sd-jwt version. if version is any, de facto same as option 1.

-> preferred direction seems to be option 1.

for implementers who used VCI issuer metadata as opposed to sd-jwt vc metadata, same openid4vp code can be used. an email will be sent out asking implementers if anyone have strong objections updating from -10 to -16 (preferrably final ver of sd-jwt vc in vp 1.1 and haip 1.1 final)

what does conformance mean? need to provide clarity:

strictly speaking, for vp 1.0, only returning sd-jwt vc -10 is compliant
for 1.1, returning any sd-jwt vc version? returning an error is ok, but not non-compliant

brentzundel · 2026-09-10T15:15:03Z

Discussed today, @Sakurann please adjust this PR according to option 1. Make sure to mention wallet and verifier requirements.

brentzundel · 2026-09-17T15:23:36Z

Discussed today, still waiting for @Sakurann to update the PR

brentzundel · 2026-09-23T23:01:11Z

+The `dc+sd-jwt` Credential Format Identifier identifies an IETF SD-JWT VC independently
+of the version of [@!I-D.ietf-oauth-sd-jwt-vc] used to issue it.
+


As above

Suggested change

The `dc+sd-jwt` Credential Format Identifier identifies an IETF SD-JWT VC independently

of the version of [@!I-D.ietf-oauth-sd-jwt-vc] used to issue it.

jogu

I don't think the "we should be explicit that this is a potential breaking change compared to the first version of 1.0" part at #726 (comment) has been captured in the spec yet. Maybe something like 'Verifiers or Wallets compliant with older versions may not accept/correctly process credentials compliant with newer versions of SD-JWT VC." (that's not a very good wording but hopefully the intent is kind of clear).

brentzundel · 2026-09-24T15:53:58Z

Discussed in call. The group felt it would be better to avoid normative language and instead have guidance for the verifier: "You should ask for SD-JWT VC 1.0, but you may not get it, up to you if that's acceptable or not."
@Sakurann please adjust PR

brentzundel · 2026-10-01T15:25:39Z

Discussed in Group today: The strong feeling in the group is we say as little as possible beyond pointing to the RFC for SD-JWT-VC

paulbastian · 2026-10-15T16:35:08Z

 - the `nonce` claim MUST be the value of `nonce` from the Authorization Request;
 - the `aud` claim MUST be the value of the Client Identifier, except for requests over the DC API where it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

+An SD-JWT Credential is expected to match the final version of [@!I-D.ietf-oauth-sd-jwt-vc]. Any differences to previous drafts are out of scope for this specification and are negotiated by the Credential Issuer, Holder and Verifier.


Suggested change

An SD-JWT Credential is expected to match the final version of [@!I-D.ietf-oauth-sd-jwt-vc]. Any differences to previous drafts are out of scope for this specification and are negotiated by the Credential Issuer, Holder and Verifier.

An SD-JWT Credential is expected to match the latest version of [@!I-D.ietf-oauth-sd-jwt-vc]. Any differences to previous drafts are out of scope for this specification and are negotiated by the Credential Issuer, Holder and Verifier.

paulbastian · 2026-10-15T16:35:29Z

+A Wallet's inability to determine the version of [@!I-D.ietf-oauth-sd-jwt-vc]
+that the Issuer used to issue a Credential of the `dc+sd-jwt` Credential Format
+MUST NOT, on that basis alone, cause the Wallet to treat the Credential as
+non-matching or to withhold it from a response it would otherwise return to the
+Verifier. All other conditions for returning a Credential, including satisfying
+the DCQL query and obtaining the required End-User authorization apply.
+
+A Verifier MUST be prepared to receive a Credential of the `dc+sd-jwt` Credential
+Format that was issued under a version of [@!I-D.ietf-oauth-sd-jwt-vc] other than
+the one it expects. A Verifier MAY respond with an error if it cannot process the
+received version. Doing so is a local processing decision and does not render the
+Wallet's response non-conformant.
+


Update this section, once we agreed on top

paulbastian · 2026-10-15T16:36:48Z

-The Credential Format Identifier is `dc+sd-jwt`.
+The Credential Format Identifier is `dc+sd-jwt`. 
+
+The `dc+sd-jwt` Credential Format Identifier identifies an IETF SD-JWT VC independently


I wonder if this section should be merged with the new text underneath

jogu · 2026-10-15T22:02:13Z

 - the `nonce` claim MUST be the value of `nonce` from the Authorization Request;
 - the `aud` claim MUST be the value of the Client Identifier, except for requests over the DC API where it MUST be the Origin prefixed with `origin:`, as described in (#dc_api_response).

+An SD-JWT Credential is expected to match the final version of [@!I-D.ietf-oauth-sd-jwt-vc]. Any differences to previous drafts are out of scope for this specification and are negotiated by the Credential Issuer, Holder and Verifier.


As I mentioned at the end of the WG call today, I really don't know how to apply this statement in the test suite. The test suite needs to have a selected version to test received credentials against and to generate credentials that are compliant to. Does the working group want two different test suites, one for HAIP 1.0 Final with VP 1.0 Final and a different one for HAIP 1.0 with VP 1.0 Errata? That doesn't sound like a good / intended outcome.

Additionally regardless of whether we use 'latest' or 'final' I don't see how we can publish an errata until SD-JWT VC is published as an RFC; if we publish the errata and then a new version of SD-JWT VC is published that's just a moving target for testing and for implementors.

kohex-net · 2026-10-20T10:17:19Z

Hello,

I'm commenting as a Verifier implementer targeting EUDI deployments.

I support the move to non-normative guidance here, and I agree with @Sakurann 's point that many wallets genuinely cannot tell which SD-JWT VC revision they hold. Mandating a revision would create non-conformance that wallets have no way to avoid.

What I would like to raise is that the current wording leaves Verifier behaviour undefined in a context where the references already conflict :

The EUDI Essential Standards and Technical Specifications list references OpenID4VP 1.0 alongside draft-ietf-oauth-sd-jwt-vc-13 for PID and EAA, while VP 1.0 itself references -10.
It also pins draft-ietf-oauth-status-list-13 separately, and the status list format is one of the breaking deltas between those revisions, together with 'vct#integrity' and type metadata.

So a Verifier operating in that context cannot derive a defensible expectation from the references as they stand, and the note as drafted does not help it decide.

Three narrow requests, all compatible with keeping this non-normative:

Determinability A Verifier should have some way to constrain or learn the SD-JWT VC revision of what it receives, whether in the DCQL query or in metadata. If wallets cannot determine their own revision today, I would suggest the note say so explicitly as a known limitation, rather than leaving Verifier behaviour unspecified. "Be prepared to receive a different revision" is hard to implement against without a way to find out which one arrived.
Name a concrete recommended revision +1 to @awoie on -13. A named target in the note, even as a recommendation, is more actionable than "the final version", and it matches what the EUDI STS list currently references.
Symmetry on conformance The proposed text states that an error response is a local processing decision and does not make the Wallet's response non-conformant. Could the converse be stated as well, that a Verifier which rejects a credential whose revision it did not request also remains conformant ? Asymmetric language here is likely to be read into certification criteria later, and Verifiers would be on the wrong side of it.

If revision pinning belongs in HAIP rather than in VP core, I am happy to take that part there instead. A profile-level pin seems like the right place for it, and HAIP is already in the EUDI reference set.

brentzundel · 2026-10-22T15:47:42Z

 * OpenID Federation 1.0 draft -43 [@!OpenID.Federation]
 * SIOPv2 draft -13 [@!SIOPv2]
 * Selective Disclosure for JWTs (SD-JWT) draft -22 [@!I-D.ietf-oauth-selective-disclosure-jwt]
-* SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -09 [@!I-D.ietf-oauth-sd-jwt-vc]
+* SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -19 [@!I-D.ietf-oauth-sd-jwt-vc]
 * Fully-Specified Algorithms for JOSE and COSE draft -13 [@!I-D.ietf-jose-fully-specified-algorithms]


Discussed in Group, need to remove all except SIOPv2, as all the rest are final (or will be by the time we publish).
@jogu will open an issue to track the possibility of removing normative reference to SIPOv2

Issue for thinking about removing SOIPv2 normative reference: #810

why not remove SIOP too.

brentzundel · 2026-10-22T15:48:58Z

Discussed today: for testing concerns, tests shouldn't fail but should result in warnings. We adjusted normative language.
One final change needed as described here: https://github.com/openid/OpenID4VP/pull/726/changes#r4350469770

kohex-net · 2026-10-22T17:08:25Z

Verifier implementer again, now that the text has settled around @paulbastian's proposal.

Two things on that sentence, from a deployed Verifier's point of view.

On "latest" vs "final" : for anyone already in production "latest" is the harder of the two. It means the version the spec expects moves every time a new draft is posted, with no event to plan a release around. "final" at least gives one.
@jogu made the testing version of this point and the implementation version is the same. If "latest" is what unblocks publication, could it be bounded instead, something like the version VP 1.0 final references up to the latest, which is close to what @jogu suggested in the format identifier thread ?

On "are negotiated by the Credential Issuer, Holder and Verifier" : negotiated through what ?
Option 3 was the mechanism for that and it wasn't taken, so under option 1 there's a single dc+sd-jwt identifier and nothing in the request or the response to negotiate on. I'm not asking to reopen option 3, but as written the sentence points at a channel the protocol doesn't provide. Leaving the differences to ecosystem profiles would at least name somewhere the pinning can happen.

Sakurann · 2026-10-23T13:55:46Z

 * OpenID Federation 1.0 draft -43 [@!OpenID.Federation]
 * SIOPv2 draft -13 [@!SIOPv2]
 * Selective Disclosure for JWTs (SD-JWT) draft -22 [@!I-D.ietf-oauth-selective-disclosure-jwt]


Suggested change

* OpenID Federation 1.0 draft -43 [@!OpenID.Federation]

* SIOPv2 draft -13 [@!SIOPv2]

* Selective Disclosure for JWTs (SD-JWT) draft -22 [@!I-D.ietf-oauth-selective-disclosure-jwt]

* SIOPv2 draft -13 [@!SIOPv2]

Sakurann · 2026-10-23T13:57:29Z

 * Selective Disclosure for JWTs (SD-JWT) draft -22 [@!I-D.ietf-oauth-selective-disclosure-jwt]
-* SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -09 [@!I-D.ietf-oauth-sd-jwt-vc]
+* SD-JWT-based Verifiable Credentials (SD-JWT VC) draft -19 [@!I-D.ietf-oauth-sd-jwt-vc]
 * Fully-Specified Algorithms for JOSE and COSE draft -13 [@!I-D.ietf-jose-fully-specified-algorithms]


Suggested change

* Fully-Specified Algorithms for JOSE and COSE draft -13 [@!I-D.ietf-jose-fully-specified-algorithms]

fixes #659 by changing typo in sd-jwt-vc version

d703d58

Sakurann requested review from awoie, bc-pi, c2bo, danielfett, nklomp and paulbastian April 26, 2026 20:41

Sakurann added the editorial label Apr 26, 2026

paulbastian approved these changes Apr 27, 2026

View reviewed changes

jogu requested changes May 7, 2026

View reviewed changes

update sd-jwt vc version

4871d4d

Sakurann requested a review from jogu May 15, 2026 16:48

awoie reviewed May 27, 2026

View reviewed changes

awoie requested changes May 27, 2026

View reviewed changes

fkj requested review from fkj and javereec June 4, 2026 15:15

jogu requested changes Jun 10, 2026

View reviewed changes

brentzundel added the security label Aug 3, 2026

brentzundel mentioned this pull request Aug 27, 2026

Normatively define how an SD-JWT VC is returned in vp_token #782

Merged

apply option 1 changes fromt he WG discussion

b20da37

Sakurann requested review from awoie and jogu September 18, 2026 14:03

apply option 1 changes fromt he WG discussion to 1.1 too

44845cc

brentzundel reviewed Sep 23, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md

brentzundel reviewed Sep 23, 2026

View reviewed changes

jogu reviewed Sep 24, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md

c2bo reviewed Sep 24, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

paulbastian reviewed Oct 2, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

Apply suggestion from @paulbastian

0c65cbe

paulbastian reviewed Oct 15, 2026

View reviewed changes

jogu reviewed Oct 15, 2026

View reviewed changes

brentzundel reviewed Oct 22, 2026

View reviewed changes

Comment thread 1.0/openid-4-verifiable-presentations-1_0.md Outdated

Apply suggestion from @brentzundel

8a7f1f7

brentzundel reviewed Oct 22, 2026

View reviewed changes

jogu mentioned this pull request Oct 22, 2026

Remove normative reference to SIOP? #810

Open

Sakurann commented Oct 23, 2026

View reviewed changes

	- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.
	- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2.4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

		The `dc+sd-jwt` Credential Format Identifier identifies an IETF SD-JWT VC independently
		of the version of [@!I-D.ietf-oauth-sd-jwt-vc] used to issue it.

	An SD-JWT Credential is expected to match the final version of [@!I-D.ietf-oauth-sd-jwt-vc]. Any differences to previous drafts are out of scope for this specification and are negotiated by the Credential Issuer, Holder and Verifier.
	An SD-JWT Credential is expected to match the latest version of [@!I-D.ietf-oauth-sd-jwt-vc]. Any differences to previous drafts are out of scope for this specification and are negotiated by the Credential Issuer, Holder and Verifier.

Conversation

Sakurann commented Apr 26, 2026

Uh oh!

c2bo commented May 1, 2026

Uh oh!

brentzundel commented May 7, 2026

Uh oh!

jogu left a comment

Choose a reason for hiding this comment

Uh oh!

brentzundel commented May 14, 2026

Uh oh!

Sakurann commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Sakurann commented May 15, 2026

Uh oh!

c2bo commented May 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

awoie left a comment

Choose a reason for hiding this comment

Uh oh!

paulbastian commented Jun 4, 2026

Uh oh!

jogu Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

javereec commented Jul 2, 2026

Uh oh!

awoie commented Jul 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brentzundel commented Jul 16, 2026

Uh oh!

jogu commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brentzundel commented Aug 13, 2026

Uh oh!

Sakurann commented Aug 31, 2026

Uh oh!

brentzundel commented Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brentzundel commented Sep 17, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jogu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

brentzundel commented Sep 24, 2026

Uh oh!

brentzundel commented Oct 1, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kohex-net commented Oct 20, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Sakurann commented May 15, 2026 •

edited

Loading

jogu Jun 10, 2026 •

edited

Loading

awoie commented Jul 3, 2026 •

edited

Loading

jogu commented Aug 10, 2026 •

edited

Loading

brentzundel commented Sep 10, 2026 •

edited

Loading