Original text:
manifest used to sign the Signed Statement is written in the "kid" header.  5.1.2. Many Issuers issue Signed Statements about different Artifacts under

Reviewer comments:
This PR attempts to address the problem of documenting the various ways that known key content types, such as and are discovered from opaque strings or URIs such as and . This PR also explains how DIDs are similar to OIDC.
I have a working demo of this on URL, URL URL Its also possible to do same thing with did methods other than , for example ... There is a demo of that working with index db here: URL This shows that there is interoperability across issuers that use different did methods, that conform to the same resolution and dereferencing interfaces.
made comments, but I think a bit more discussion/work is needed.Asked Kristina to also look at this.a proposal for discussion @ IETF 117 Hackathon and meeting seems very useful to me. :+1: LGTM to merge as a baseline for future discussion

Revised text:
manifest used to sign the Signed Statement is written in the "kid" header. <ins> "kid" MUST either be an absolute URL, or a relative URL.  Relative URL MUST be relative to an "iss" value.  When relative URL is used, "iss" MUST also be present in the protected header. Resolving "kid" MUST return an identity document of a registered content type (a set of public keys).  In the case of "kid" being an absolute DID URL, the identity document is called a DID Document, and is expected ot have content type "application/did+json". To dereference a DID URL, it first MUST be resolved.  After that the fragment is processed according to the media type. For example, when resolving "did:example:123#key-42", first, the identity document for "did:example:123" is resolved as content type "application/did+json", next, the fragment "#key-2" is dereferenced to a verification method that contains a "publicKeyJwk" property. The content type of "publicKeyJwk" is expected to be "application/ jwk+json". The details of both "DID resolution" and "DID dereferencing" are out of scope for this document. The "iss" or "kid", might not be DID URLs, however the following interfaces MUST be satisfied in order to ensure issuer identity documents, and associated keys are discoverable in a consistent manner. 5.1.1.1. The value of "id" might be found the "iss" or "sub" claims if they are present in the protected header or payload. "resolve = (id: string, accept: content_type = 'application/ did+json') => idDocument (of content type application/did+json).  " For example: "did:example:123 " Might resolve to: "{ "id": "did:example:123", "verificationMethod": [{ "id": "#key-42", "type": "JsonWebkey", "controller": "did:example:123", "publicKeyJwk": { "kty": "EC", "crv": "P-384", "alg": "ES384", "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH", "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd" } }] } " Editor note, we might wish to eliminate this intermediate identity document content type, by treating it as an alterative encoding of "application/jwk-set+json" or "application/cose-key-set". However, there is no media type fragment processing directive that would enable dereferencing the known key set content types, listed above. 5.1.1.1.1. For well known token types, such as "id_token" or "access_token". "iss" MUST be a URL, and it MUST have keys discoverable in the following way: "iss" can be used to build a ".well-known" URL to discovery the issuer's configuration. For example, "iss" "contoso.example" will have the following open id connect configuration URL. "https://contoso.example/.well-known/openid-configuration". This URL will resolve to a JSON document which contains the property: "jwks_uri", for example "https://contoso.example/.well-known/ jwks.json" This URL will resolve to a JSON document of content type "application/jwk-set+json", which will contain specific keys... for example: ```json { "keys": [ { "alg": "RS256", "kty": "RSA", "use": "sig", "n": "wW9TkSbcn5FV3iUJ-812sqTvwTGCFrDm6vD2U-g23gn6rrBdFZQbf2bgEnSkolp h6CanOYTQ1lKVhKjHLd6Q4MDVGidbVBhESxib2YIzJVUS- 0oQgizkBEJxyHI4Zl3xX_sdA_yegLUi-Ykt_gaMPSw_vpxe-pBxu-jd14i-jDfwoPJUdF 8ZJGS9orCPRiHCYLDgOscC9XibH9rUbTvG8q4bAPx9Ox6malx4OLvU3pXVjew6LG3iBi2 YhpCWe6voMvZJYXqC1n5Mk_KOdGcCFtDgu3I56SGSfsF7- tI7qG1ZO8RMuzqH0LkJVirujYzXrnMZ7WgbMPXmHU8i4z04zw", "e": "AQAB", "kid": "NTBGNTJEMDc3RUE3RUVEOTM4NDcyOEFDNzEyOTY5NDNGOUQ4OEU5OA", "x5t": "NTBGNTJEMDc3RUE3RUVEOTM4NDcyOEFDNzEyOTY5NDNGOUQ4OEU5OA", "x5c": [ "MIIDCzCCAfOgAwIBAgIJANPng0XRWwsdMA0GCSqGSIb3DQEBBQUAMBwxGjA YBgNVBAMMEWNvbnRvc28uYXV0aDAuY29tMB4XDTE0MDcxMTE2NTQyN1oXDTI4MDMxOTE2 NTQyN1owHDEaMBgGA1UEAwwRY29udG9zby5hdXRoMC5jb20wggEiMA0GCSqGSIb3DQEBA QUAA4IBDwAwggEKAoIBAQDBb1ORJtyfkVXeJQn7zXaypO/BMYIWsObq8PZT6DbeCfqusF 0VlBt/ZuASdKSiWmHoJqc5hNDWUpWEqMct3pDgwNUaJ1tUGERLGJvZgjMlVRL7ShCCLOQ EQnHIcjhmXfFf+x0D/J6AtSL5iS3+Bow9LD++nF76kHG76N3XiL6MN/Cg8lR0XxkkZL2i sI9GIcJgsOA6xwL1eJsf2tRtO8byrhsA/H07HqZqXHg4u9TeldWN7DosbeIGLZiGkJZ7q +gy9klheoLWfkyT8o50ZwIW0OC7cjnpIZJ+wXv60juobVk7xEy7OofQuQlWKu6NjNeucx ntaBsw9eYdTyLjPTjPAgMBAAGjUDBOMB0GA1UdDgQWBBTLarHdkNa5CzPyiKJU51t8JWn 9WTAfBgNVHSMEGDAWgBTLarHdkNa5CzPyiKJU51t8JWn9WTAMBgNVHRMEBTADAQH/MA0G CSqGSIb3DQEBBQUAA4IBAQA2FOjm+Bpbqk59rQBC0X6ops1wBcXH8clnXfG1G9qeRwLEw Sef5HPz4TTh1f2lcf4Pcq2vF0HbVNJFnLVV+PjR9ACkto+v1n84i/U4BBezZyYuX2ZpEb v7hV/PWxg8tcVrtyPaj60UaA/pUA86CfYy+LckY4NRKmD7ZrcCzjxW2hFGNanfm2FEryx XA3RMNf6IiW7tbJ9ZGTEfA/DhVnZgh/e82KVX7EZnkB4MjCQrwj9QsWSMBtBiYp0/vRi9 cxDFHlUwnYAUeZdHWTW+Rp2JX7Qwf0YycxgyjkGAUEZc4WpdNiQlwYf5G5epfOtHGiwiJ S+u/nSYvqCFt57+g3R+" ] }, { "alg": "RS256", "kty": "RSA", "use": "sig", "n": "ylgVZbNR4nlsU_AbU8Zd7ZhVfmYuwq-RB1_YQWHY362pAed-qgSXV1Qm KwCukQ2WDsPHWgpPuEf3O_acmJcCiSxhctpBr5WKkji5o50YX2FqC3xymGkYW5NilvFzn KaKU45ulBVByrcb3Vt8BqqBAhaD4YywZZKo7mMudcq_M__f0_tB4fHsHHe7ehWobWtzAW 7_NRP0_FjB4Kw4PiqJnChPvfbuxTCEUcIYrshRwD6GF4D_oLdeR44dwx4wtEgvPOtkQ5X IGrhQC_sgWcb2jh7YXauVUjuPezP- VkK7Wm9mZRe758q43SWxwT3afo5BLa3_YLWazqcpWRXn9QEDWw", "e": "AQAB", "kid": "aMIKy_brQk3nLd0PKd9ln", "x5t": "-xcTyx47q3ddycG7LtE6QCcETbs", "x5c": [ "MIIC/TCCAeWgAwIBAgIJH62yWyX7VxxQMA0GCSqGSIb3DQEBCwUAMBwxGjA YBgNVBAMTEWNvbnRvc28uYXV0aDAuY29tMB4XDTIwMDMxMTE5Mjk0N1oXDTMzMTExODE5 Mjk0N1owHDEaMBgGA1UEAxMRY29udG9zby5hdXRoMC5jb20wggEiMA0GCSqGSIb3DQEBA QUAA4IBDwAwggEKAoIBAQDKWBVls1HieWxT8BtTxl3tmFV+Zi7Cr5EHX9hBYdjfrakB53 6qBJdXVCYrAK6RDZYOw8daCk+4R/c79pyYlwKJLGFy2kGvlYqSOLmjnRhfYWoLfHKYaRh bk2KW8XOcpopTjm6UFUHKtxvdW3wGqoECFoPhjLBlkqjuYy51yr8z/9/T+0Hh8ewcd7t6 Fahta3MBbv81E/T8WMHgrDg+KomcKE+99u7FMIRRwhiuyFHAPoYXgP+gt15Hjh3DHjC0S C8862RDlcgauFAL+yBZxvaOHthdq5VSO497M/5WQrtab2ZlF7vnyrjdJbHBPdp+jkEtrf 9gtZrOpylZFef1AQNbAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFPV dE4SPvuhlODV0GOcPE4QZ7xNuMA4GA1UdDwEB/wQEAwIChDANBgkqhkiG9w0BAQsFAAOC AQEAu2nhfiJk/Sp49LEsR1bliuVMP9nycbSz0zdp2ToAy0DZffTd0FKk/wyFtmbb0UFTD 2aOg/WZJLDc+3dYjWQ15SSLDRh6LV45OHU8Dkrc2qLjiRdoh2RI+iQFakDn2OgPNgquL+ 3EEIpbBDA/uVoOYCbkqJNaNM/egN/s2vZ6Iq7O+BprWX/eM25xw8PMi+MU4K2sJpkcDRw oK9Wy8eeSSRIGYnpKO42g/3QI9+BRa5uD+9shG6n7xgzAPGeldUXajCThomwO8vInp6Vq Y8k3IeLEYoboJj5KMfJgOWUkmaoh6ZBJHnCogvSXI35jbxCxmHAbK+KdTka/ Yg2MadFZdA==" ] } ] } ``` If SCITT wanted to be interoperable with OIDC, we would define key dereferencing in a way that was compatible with how OIDC handles it today. 5.1.1.2. "kid" is always present in the protected header. If "iss" is also present, "kid" MUST be a relative URL to "iss", otherwise "kid" MUST be an absolute URL that starts with "iss". "id" = "kid" if "iss" is undefined, or "iss" + "#" + "kid" when "iss" is defined. See also draft-ietf-cose-cwt-claims-in-headers [1]. "dereference = (id: string, accept: content_type = 'application/ jwk+json') => publicKeyJwk (of content type application/jwk+json).  " For example, when DIDs are used: "did:example:123#key-42 " Might dereference to: "{ "kty": "EC", "crv": "P-384", "alg": "ES384", "x": "LCeAt2sW36j94wuFP0gNEIHDzqR6Nh_Udu2ObLer3cKFBCaAHY1svmbPV69bP3RH", "y": "zz2SkcOGYM6PbYlw19tcbpzo6bEMYHIwGBnN5rd8QWykAprstPdxx4U0uScvDcYd" } " </ins> 5.1.2. Many Issuers issue Signed Statements about different Artifacts under