Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)

[Tom Jones <[e-mail]>]

I should have added - if you get a verifiable presentation from a wallet
with a verifiable credential - it is my understanding that the VP is proof
possession - in the sense that the VC has been processed by the subject to
create the VP.

I started to collect some information about that here - but it is far from
complete.
https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme

..tom


On Sun, Jan 21, 2024 at 1:03 PM Tom Jones <[e-mail]>
wrote:

> Technically oauth is about authorization not authentication. And
> technically attestation is provided by rats and not oauth. So if you think
> that you are confused, so is everyone else at this point.
>
> thx ..Tom (mobile)
>
> On Sun, Jan 21, 2024, 11:51 AM <[e-mail]> wrote:
>
>> Hi Tom et al.
>>
>> Earlier this or last week someone wrote about the possibility of looking
>> at things from a relying party's perspective.
>>
>> As a relying party I need a method for a user to prove who and what they
>> are or have. Hence the user needs to present evidence as proof of who they
>> are and in what capacity or holding they are presenting.
>>
>> I have been very involed in SSI and verfiable credentials (VC). Which is
>> becoming a major way of presentiing evidence as proof.
>>
>> VCs are cryptographic proofs for a relying party. However the relying
>> party also needs proof of who is presenting.  WShen you combine the two you
>> now address proof of possession problem which has been the underlying
>> weakness of public key cryptography.
>>
>> I was not trying to be misleading. I  was responding to the discussion
>> below regarding " digital proof, digital credential, secure and privacy
>> preserving fashion, collusion between holders, collection limitation,
>> privacy principles, unlinkability between verifiers and more.
>>
>> I have done a lot of work in this area and believe have addressed the
>> proof of possession issue of public key cryptography because I can
>> cryptographically and privately bind a users biometrics with both their
>> public and private keys and can embed the same with veriable credentials.
>> Whereas when I see the OAuth work it seems to be trying to create an audit
>> trail rather than solving the proof of posession by the original
>> client/wallet initiating the transaction.
>>
>> As I said I was not trying to be misleading. At the same time I do not
>> see the current OAuth track as solving this underlying proof of possesion
>> problem that is needed by the relying party.
>>
>> Best
>>
>> Don
>>
>> And for the record I am not a technologist. I am a person who tries to
>> solve business problems.
>>
>>
>>
>> On 2024-01-21 11:08, Tom Jones wrote:
>>
>> yes - i see that's what you are doing and think it is not only wrong, but
>> misleading.
>> Somehow words like trust and proof are given technological definitions by
>> technologists that do not reflect the words existing meaning, but seek to
>> gain reflected credence by their use in technological contexts. .  (like
>> proof -> a cryptographic ability that is verifiable)
>> Perhaps you don't care that these are incorrect uses of the word?
>>
>> ..tom
>>
>> On Fri, Jan 19, 2024 at 10:46 AM <[e-mail]> wrote:
>>
>> You present evidence as proof.
>>
>>
>> On 2024-01-19 12:50, Tom Jones wrote:
>>
>>
>> Proof seems to be yet another term for which we already have other terms.
>> Can anyone explain the difference between:
>> proof
>> presentation
>> evidence.
>>
>> ..tom
>>
>> On Fri, Jan 19, 2024 at 4:28 AM Denis <[e-mail]> wrote:
>>
>> Hi Giuseppe,
>>
>> Ciao Denis,
>>
>> Thank you! By points.
>>
>> First, I still have a vocabulary problem. The text states:
>>
>> A *digital credential* may be presented to a verifier long after it has
>> been issued.
>>
>> It should rather say: A *digital proof *(derived from a digital
>> credential) may be presented to a verifier.
>>
>> Then, the text states:
>>
>> Verifier:
>>
>> Entity that relies on the validity of the Digital Credentials presented
>> to it.
>>
>>
>> I should rather say:
>>
>>         Verifier:
>>
>>           Entity that relies on the validity of the *digital proof*
>> presented to it.
>>
>>
>>
>> OAuth Status List can be accessed by a Verifier when an internet
>> connection is present.
>>
>>    - This does not correspond to the flows of the figure.
>>
>>
>> the section enumerates the differences between oauth status list and
>> oauth status attestations.
>> The subject of the sentence is then the oauth status list, below I report
>> the original text in that point:
>>
>> *Offline flow*: OAuth Status List can be accessed by a Verifier when an
>> internet connection is present. At the same time, OAuth Status List defines
>> how to provide a static Status List Token, to be included within a Digital
>> Credential. This requires the Wallet Instance to acquire a new Digital
>> Credential for a specific presentation. Even if similar to the OAuth Status
>> List Token, the Status Attestations enable the User to persistently use
>> their preexistent Digital Credentials, as long as the linked Status
>> Attestation is available and presented to the Verifier, and not expired.
>>
>>  OK.
>>
>>
>>
>>    - What about the support of "blinded link secrets" and "link secrets"
>>    (used with anonymous credentials) ?
>>
>>
>> Unfortunately I don't have these in the EUDI ARF and in my implementative
>> asset but this doesn't prevent us to not include it in the draft.
>>
>> When writing this, I had the use case of BBS+ in mind.
>>
>> Published versions of the ARF is available here:
>> https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md
>>
>> The word "privacy" is used once in a single sentence copied below which
>> is:
>>
>> Attestation exchange Protocol. This protocol defines how to request and
>> present the PID and the (Q)EAA in a secure and *privacy* preserving
>> fashion.
>>
>> In the context of a single data controller, ISO 29100 identifies eleven
>> privacy principles:
>>
>> 1.   Consent and choice
>> 2.   Purpose legitimacy and specification
>> 3.   Collection limitation
>> 4.   Data minimization
>> 5.   Use, retention and disclosure limitation
>> 6.   Accuracy and quality
>> 7.   Openness, transparency and notice
>> 8.   Individual participation and access
>> 9.   Accountability
>> 10. Information security
>> 11. Privacy compliance
>>
>> None of them is being addressed.
>>
>> In addition, when considering a distributed system used by human beings, *two
>> additional **privacy principles *need to be taken into consideration
>> and none of them is mentioned:
>>
>> *      Unlinkability *of holders between verifiers
>>
>> *      Untrackability* of holders by a server, (i.e., a property
>> ensuring that it is not possible for a server to know by which verifier the
>> information it issues to a caller,
>>                                 or derivations from it, will be consumed.
>> In other words : Can the server act as Big Brother ?
>>
>> Margrethe *Vestager*, [former] Executive Vice-President for a Europe Fit
>> for the Digital Age said:
>>
>> *      "The European digital identity will enable us to do in any Member
>> State as we do at home without any extra cost and fewer hurdles. *
>> *      Be that renting a flat or opening a bank account outside of our
>> home country. And do this in a way that is secure and transparent. *
>> *      So that we will decide how much information we wish to share about
>> ourselves, with whom and for what purpose.*
>>
>> Source:  https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2663
>>
>>
>> This statement is not mentioned in the ARF.
>>
>>
>> An additional important *security consideration *needs to be addressed:
>>
>> *      Collusions between **holders *(natural persons), which is
>> difficult to support while at the same time the "*collection limitation*"
>> privacy principle is considered.
>>
>> This can be illustrated by the following example:
>>
>>       Can Alice (12) collude with Bob (25) to access to a verifier
>> delivering age-restricted services or products (e.g., like the condition of
>> being over 18) ?
>>      Since Bob is over 25, he can obtain some "proof" that he is over
>> 18.  Can Alice (12) can advantage of this proof to access to age-restricted
>> services or products ?
>>
>> Would you like to propose your idea in the current text (github issue or
>> PR) about the possibility to enable this technology?
>>
>> On page 45 from COM(2021) 281 final, (
>> https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52021PC0281
>> ) there is the following statement:
>>
>>            "  A strengthened *privacy-by-design approach* could yield
>> additional benefits since the wallet would not require intermediaries
>>             in the process of asserting the attributes, thus enabling the
>> citizen to communicate directly with the service and credential providers".
>>
>> Every IETF draft now includes both a *Security Consideration* section
>> and a *Privacy Consideration *section. There is no such sections in ARF
>> 1.0.X.
>>
>> Since ARF 1.0.X has not listed any privacy principle, it could not follow
>> a *privacy-by-design approach.*
>>
>>
>> Before defining technical solutions, requirements would first need to be
>> identified and agreed. At the moment, none of the five experiments is
>> considering
>> the previously identified privacy principles (nor the above security
>> consideration).
>>
>> There should first be an agreement to add both a *Security Consideration*
>> section and a *Privacy Consideration *section to the ARF.
>>
>> Another consideration has been raised: the cryptographic algorithms being
>> used should be quantum resistant.
>>
>> This is a good wish but nobody knows when this would really be needed.
>>
>> BBS+ is not believed to be quantum resistant. However, if one-time
>> digital signatures are considered, they can be quantum resistant
>> (e.g., using SHA-3 and Lamport signatures). This would natively prevent
>> verifiers to use the public key present in a credential proof to link
>> accesses from
>> the same holder on different servers. This would mandate to issue batches
>> of credentials in advance, which is only considered at a possible
>> *option*
>> at the moment. This would also prevent using a "digital credential serial
>> number" to perform a linkage between different digital proofs.
>>
>> For signing digital credentials, the FIPS 204 (DRAFT)
>> MODULE-LATTICE-BASED DIGITAL SIGNATURE STANDARD might be considered.
>>
>> This does not mean in anyway that these algorithms should be used *now*,
>> but it would be good to already know which kinds algorithms will be usable
>> when it will become really necessary to achieve quantum resistance.
>>
>> I mean, the current text satisfies the security requirements, in addition
>> to this we can explore and enable additional methods, in particular when
>> these brings additional benefits.
>>
>>
>>    - A major section is missing: "*Privacy considerations*".
>>
>>
>> yes, the best is yet to come ��
>>
>> When doing a *privacy-and-security-by-design *approach*, *once the model
>> and the key actors have be identified, these two sections should be
>> filled-in first.
>>
>> :-)
>>
>>
>>
>>    - One of many privacy principles is:  "unlinkability between
>>    verifiers".
>>
>>
>> yes. The scope of this specs is providing a "static" way to give a
>> verifiable proof. In the privacy consideration I would start with the sotry
>> of Giuseppe that presents his credential of org affiliation to an RP,
>> giving org name, entitlements and position. Having the url and the index of
>> the revocation status of that credential, the RP is technically able to
>> continuosly check that Giuseppe is still emploied in that organization,
>> even outside of a resonable time windows for the authorized
>> authentication/session.
>>
>> then, the scopes of this draft is all about revocation and tracking
>> prevention about the revocation checks. The problem of linkability belongs
>> to the credential and not to the status attestation (if I didn't miss
>> anything).
>>
>> Let us now come back to Status Attestations when using one-time digital
>> credentials.
>> Let us consider two cases: whether the status attestation request is done
>> by the holder or by the verifier.
>>
>> 1) If the status attestation request is done by the holder, this means
>> that it is online and in such a case, it could ask for a batch of one-time
>> digital credentials
>>      with short expiration dates without the need to request Status
>> Attestations.
>>
>> 2) If the status attestation request is done by the verifier *and if the
>> server able to provide Status Attestations is different from the server
>> issuing the digital credential*,
>>     then a query to that other server will prevent the issuer to know
>> where the digital proof has been presented by the holder. This would allow
>> the holder to get
>>     digital credentials with longer expiration dates.
>>
>> Seen from the wallet, the following strategy would be used:
>>
>>    - If the wallet knows that it is on-line, it will use or request a
>>    digital credential with a short expiration date.
>>    This will avoid the verifier to make a call when it receives the
>>    digital proof.
>>
>>    - If the wallet knows that it is off-line, it will use an already
>>    stored digital credential with a long expiration date.
>>    If the server able to provide Status Attestations is, in fact, not
>>    really independent from the server issuing the digital credential,
>>    the linkability between verifiers will be limited to servers accessed
>>    using NFC. Hence, the risk will be mitigated.
>>
>> Both types of digital credential will then have their own merits.
>>
>> Yes, I will, The sections Rationale and Privacy Consideration are the
>> most funny and we'll continue on those. Thank you for the hints, I
>> appreciate!
>>
>> In this rather long email, you have further hints.
>>
>> :-)
>>
>> Denis
>>
>>
>>
>> ------------------------------
>> *Da:* Denis <[e-mail]> <[e-mail]>
>> *Inviato:* giovedì 18 gennaio 2024 19:25
>> *A:* demarcog83 <[e-mail]> <[e-mail]>
>> *Cc:* [e-mail] <[e-mail]> <[e-mail]>; Giuseppe De
>> Marco <[e-mail]> <[e-mail]>;
>> oauth <[e-mail]> <[e-mail]>
>> *Oggetto:* Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status
>> Attestations (typo)
>>
>>
>> Non si ricevono spesso messaggi di posta elettronica da
>> [e-mail]. Informazioni sul perché è importante
>> <https://aka.ms/LearnAboutSenderIdentification>
>>
>> Questa email arriva da un mittente insolito. Assicurati che sia qualcuno
>> di cui ti fidi.
>> Giuseppe,
>>
>> You are perfectly right, I read your draft too quickly.
>>
>> 1) The text mentions near the end:
>>
>> OAuth Status List can be accessed by a Verifier when an internet
>> connection is present.
>>
>> This does not correspond to the flows of the figure.
>>
>> 2) The text states:
>>
>> " The proof of possession MUST be signed with the private key
>> corresponding to the *public key* attested by the Issuer
>> and contained within the Credential".
>>
>> What about the support of "blinded link secrets" and "link secrets" (used
>> with anonymous credentials) ?
>>
>> 3) A major section is missing: "*Privacy considerations*".
>>
>> One of many privacy principles is:  "unlinkability between verifiers".
>>
>> If or when the status attestation allows to support this privacy
>> principle, it should be indicated how it can be supported.
>> If or when it does not, this should be mentioned as well.
>>
>> Denis
>>
>> Ciao Denis,
>>
>> thank you for the quick reply and for your contribution.
>> The scope of the current draft is to provide a verifiable artifact that
>> give the proof that a specific credential is active, then not revoked.
>>
>> From your sequence diagram I read a digital credential issuance, while
>> this is not in the scope of the draft.
>> best
>>
>>
>> Il giorno gio 18 gen 2024 alle ore 10:26 Denis <[e-mail]> ha
>> scritto:
>>
>> Typo: Change: "proof *or* origin of wallet instance"
>> into               : "proof * of* origin of wallet instance".
>>
>> The figure has been corrected below.
>>
>> Denis
>>
>> Hi Giuseppe,
>>
>> The current figure in the Introduction from
>> draft-demarco-status-attestations-latest is:
>>
>> +-----------------+                             +-------------------+
>> |                 | Requests Status Attestation |                   |
>> |                 |---------------------------->|                   |
>> | Wallet Instance |                             | Credential Issuer |
>> |                 | Status Attestation          |                   |
>> |                 |<----------------------------|                   |
>> +-----------------+                             +-------------------+
>>
>>
>> +-- ----------------+                             +----------+
>> |                   | Presents credential and     |          |
>> |  Wallet Instance  | Status Attestation          | Verifier |
>> |                   |---------------------------->|          |
>> +-------------------+                             +----------+
>>
>> IMO, using the vocabulary agreed during the last BoF video conference,
>> this figure should be modified as follows:
>>
>>
>> +------------+
>> +-------------------+
>> |            | Requests *Digital Credential*            |
>> |
>> |            | and presents proof of knowledge of     |
>> |
>> |            | either a private key or a link secret  |
>> |
>> |            | and proof *of* origin of wallet instance | Credential
>> Issuer |
>> |   Holder   |--------------------------------------->|
>>  |
>> |            |                                        |
>>                   |
>> |            |    *Digital Credential*                  |
>> |
>> |            |<---------------------------------------|
>> |
>> +------------+
>> +-------------------+
>>
>>
>> +-- ---------+
>> +-------------------+
>> |            | Presents *Credential proof*              |
>>        |
>> |   Holder   |                                        |      Verifier
>>  |
>> |            |--------------------------------------->|
>>       |
>> +------------+
>> +-------------------+
>>
>> Denis
>>
>>
>>
>> Hi Hannes,
>> Thank you for your quick reaction and also to Orie for sharing.
>> I've submitted the draft, here:
>> https://datatracker.ietf.org/doc/draft-demarco-status-attestations/
>>
>>
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-demarco-status-attestations%2F&e=bcb9f84b&h=6cfb1966&f=n&p=y>
>> Regarding the term Attestation: good point. We have decided to use this
>> term since in several IETF and OpenID drafts this term seems pretty
>> established, the term Attestation is found at least in the following
>> specifications:
>>   - Attestation based client-authentication (it's in the title)
>>   - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC
>> (wallet attestation)
>>   - OpenID for Verifiable Presentations - draft 20 (verifier attestation)
>>   - OpenID for Verifiable Credential Issuance (section "Trust between
>> Wallet and Issuer": Device Attestation)
>>
>> Meantime in the eIDAS Expert group this term is going to be changed to
>> "Wallet Trust Evidence".
>>
>>
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-demarco-status-attestations%2F&e=bcb9f84b&h=6cfb1966&f=n&p=y>
>> I don't have a strong opinion on what would be the best semantic for
>> this, I just have realized the functional difference between a Digital
>> Credential and an Attestation:
>> the first requires the user to be authenticated and give consent for
>> using the secure storage. The second is obtained with a machine2machine
>> flow where no user interaction is required, the secure storage is not
>> required, no user information is contained in it since the subject is the
>> wallet instance and not the user, it cannot be (re)used without the
>> cryptographic proof of possession. Probably a discussion could start about
>> this term aiming to align several specifications on the same terminology. I
>> could say that Status Attestation is a specific artifact defined for a
>> specific context, other attestations can be defined outside the functional
>> perimeter of this specification. Let's talk about it, it doesn't matters
>> changing terms (eventually mindsets on perceivable meanings).
>>
>> Here I share some notes I picked along the last two months about this
>> brand new individual draft:
>>
>> - it is related to digital credential only, I don't expect to use it in
>> legacy infrastructure different from wallet. I really don't need this kind
>> of mechanism in OIDC or any other traditional infrastructure since these
>> doesn't show the privacy issues the wallet ecosystem has;
>> - it would interesting mentioning in the introduction that's pratically
>> an ocsp stapling like mechanism, just to give some context (credit: Paul
>> Bastien);
>> - The Rationale section needs to clarify better problems and solutions, where
>> it seems that the problem does not exist or that it is weak. A review is
>> necessary to clearly bring the benefits;
>> - Editorials mistake are still along the reading.
>>
>> thank you for your time and interest,
>> best
>>
>>
>>
>>
>>
>>
>> Il giorno mer 17 gen 2024 alle ore 21:06 <hannes.tschofenig=
>> [e-mail]> ha scritto:
>>
>> Hi Guiseppe, Francesco, Orie,
>>
>>
>>
>> @Orie: Thanks for sharing the draft.
>>
>>
>>
>> As a quick reaction: It would be good to invent a new term for
>> "attestation" in draft-demarco-status-attestations.html because this term
>> is already widely used in a different context (see RFC 9334).
>>
>>
>>
>> @Guiseppe and Francesco: It would be great if you could submit your draft
>> to OAuth or SPICE for discussion.
>>
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>>
>>
>> *From:* OAuth <[e-mail]> *On Behalf Of *Orie Steele
>> *Sent:* Mittwoch, 17. Jänner 2024 19:07
>> *To:* [e-mail]
>> *Cc:* oauth <[e-mail]>
>> *Subject:* [OAUTH-WG] OAuth Digital Credential Status Attestations
>>
>>
>> Hello Digital Credential Enthusiasts,
>>
>> See:
>> https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fpeppelinux.github.io%2Fdraft-demarco-status-attestations%2Fdraft-demarco-status-attestations.html&e=bcb9f84b&h=09ac1782&f=n&p=y>
>>
>> Note the use of the term digital credential, and the alignment to CWT
>> based credentials and CWT based credential status lists.
>>
>> As a quick summary of the editors draft above:
>>
>> It is basically a refresh-token-like approach to dynamic state, where the
>> holder retrieves updated state from the issuer at regular intervals, and
>> can then present that dynamic state directly to the verifier.
>>
>> This eliminates the herd privacy and phone home issues associated with
>> W3C Bitstring Status Lists.
>>
>> And it informs the holder of dynamic state, so the digital wallet can
>> provide a better user experience.
>>
>> However, an issuer (government or ngo) could use the interval of
>> requesting dynamic state, to track the holder... so the guidance from
>> https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-steele-spice-oblivious-credential-state%2F&e=bcb9f84b&h=31ec3f83&f=n&p=y>
>>
>> Is also relevant to this draft.
>>
>> I also learned that
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-sd-jwt-vc%2F&e=bcb9f84b&h=1dd20f32&f=n&p=y>
>>
>> Has defined a new property for expressing "Verifiable Credential" "type"
>> `vct`, which is different from how W3C defines credential types.
>>
>> W3C uses the expanded IRI for the graph node type, based on the JSON-LD
>> context.
>>
>> For example with:
>>
>> {
>>   "@context": [
>>     "https://www.w3.org/ns/credentials/v2
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fv2&e=bcb9f84b&h=f582aa55&f=n&p=y>
>> ",
>>     "https://www.w3.org/ns/credentials/examples/v2
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fexamples%2Fv2&e=bcb9f84b&h=09fd0c99&f=n&p=y>
>> "
>>   ],
>>   "id": "http://university.example/credentials/1872
>> <https://urlsand.esvalabs.com/?u=http%3A%2F%2Funiversity.example%2Fcredentials%2F1872&e=bcb9f84b&h=a4458b13&f=n&p=y>
>> ",
>>   "type": ["VerifiableCredential", "ExampleAlumniCredential"],
>>   ...
>> }
>>
>> The credential type in RDF becomes "
>> https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.w3.org%2Fns%2Fcredentials%2Fexamples%23ExampleAlumniCredential&e=bcb9f84b&h=d975b89f&f=n&p=y>
>> "
>>
>> Which is different from "ExampleAlumniCredential" in JSON... More
>> evidence that RDF leads to developer confusion regarding safe typing.
>>
>> The OAuth solution does not have this confusing issue, they set the type
>> explicitly:
>>
>> {
>>  "vct": "https://credentials.example.com/identity_credential
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fcredentials.example.com%2Fidentity_credential&e=bcb9f84b&h=4de83001&f=n&p=y>
>> ",
>>  "given_name": "John",
>>  "family_name": "Doe",
>>  "email": "[e-mail]",
>>  "phone_number": "[phone]",
>>  "address": {
>>    "street_address": "123 Main St",
>>    "locality": "Anytown",
>>    "region": "Anystate",
>>    "country": "US"
>>  },
>>  "birthdate": "1940-01-01",
>>  "is_over_18": true,
>>  "is_over_21": true,
>>  "is_over_65": true,
>>  "status": {
>>     "status_attestation": {
>>         "credential_hash_alg": "S256",
>>     }
>>  }
>> }
>>
>> Regards,
>>
>> OS
>>
>> --
>>
>>
>>
>>
>> *ORIE STEELE*Chief Technology Officer
>> www.transmute.industries
>> <https://urlsand.esvalabs.com/?u=http%3A%2F%2Fwww.transmute.industries&e=bcb9f84b&h=5399df5d&f=n&p=y>
>>
>>
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Ftransmute.industries%2F&e=bcb9f84b&h=1f9092b6&f=n&p=y>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>>
>>
>> _______________________________________________
>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth <https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&e=bcb9f84b&h=b6441af9&f=n&p=y>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>