Minor inconsistancies and misalignments in SSF Spec document

[beyond-james-slocum]

I wanted to capture some conflicting examples in the SSF spec document, if these have already been addressed for the up coming V1-Final effort you can disregard.

1. In the example of "conforming events" defined in The SSF Standard, Section 5 The txn field defined in the examples are json numeric values

"iat": 1520364019,
"txn": 8675309,
"aud": "636C69656E745F6964",

However the txn claim is defined here in the SET token standard, is defined as an Optional String

"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.

So all of these examples should be updated to quote the txn value.

2. The CAEP event defined in the events claims does not match the format as defined in the CAEP Standard
   the reason_admin and reason_user are defined as a JSON OBJECT that is a set of BCP47 (RFC5646) language tags, with their localized display string. So to correct the above example, it should be

{
    ...,

    "reason_admin" : {
        "en" : "Policy Violation: C076E82F"
    },
    "reason_user" : {
        "en" : "Landspeed violation."
    }
}

3. In section [10.1.3] there is an example with a sub_id with format = phone. This is not a valid id according to this spec, it should be phone_number as defined in
   Subject Identifiers

4. In section [10.1.3] there is another example, where the CAEP event uses the event URL:
   https://schemas.openid.net/secevent/caep/event-type/token-claims-changed with
   an "ed" on the end of change, but in the spec here
   you can see it's defined as: https://schemas.openid.net/secevent/caep/event-type/token-claims-change without the "ed".

[FragLegs]

Thank you!

For whoever picks this up:

• The second point was addressed in Update reason_admin and reason_user in examples to object #193 (merged just moments before this issue was posted).
• Points 3 and 4 should be handled as part of Incorporate Section 10 earlier in the spec #226 (tagging it so they don't get lost in the shuffle).