Orie: For the sake of terminology, please note that SD-JWT is a container format similar to JWT, while SD-JWT VC is a credential format that uses SD-JWT. Credentials in the SD-JWT VC format use a specific media type, "application/vc+sd-jwt", populated in the typ header. Cryptographic key binding or "cnf" is optional.
Thanks, Oliver ________________________________ From: SPICE <spice-boun...@ietf.org> on behalf of Orie Steele <orie@transmute.industries> Sent: Tuesday, January 23, 2024 2:48 PM To: Tom Jones <thomasclinganjo...@gmail.com> Cc: Watson Ladd <watsonbl...@gmail.com>; sp...@ietf.org <sp...@ietf.org>; Giuseppe De Marco <gi.dema...@innovazione.gov.it>; oauth <oauth@ietf.org> Subject: Re: [SPICE] [OAUTH-WG] R: OAuth Digital Credential Status Attestations (typo) EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. There are at least 2 kinds of vp. W3C has them and they can be secured or not. SD-JWT has them, and they can have key binding or not. An sd-jwt without key binding is indistinguishable from a credential except for looking at the unprotected disclosures. SD-JWT has a section on forwarding presentations, that talks about redacting fields and presenting in a cases where key binding is not required. Key binding is basically the secured version of a W3C VP, but restricted to a single credential, instead of multiple credentials. Key binding is not required afaik. Therefore presentation can be forwarded / reused. OS On Tue, Jan 23, 2024, 12:51 AM Tom Jones <thomasclinganjo...@gmail.com<mailto:thomasclinganjo...@gmail.com>> wrote: VPs are not reused AFAIK. thx ..Tom (mobile) On Mon, Jan 22, 2024, 4:41 PM Watson Ladd <watsonbl...@gmail.com<mailto:watsonbl...@gmail.com>> wrote: It could be a resused one obtained from a different context. Does that matter? Depends on application. There's also a question of what it means the subject processed it: people don't process VCs, their computers do. (Hence the terminology of User Agent, not user, in the W3C) On Sun, Jan 21, 2024 at 4:46 PM Tom Jones <thomasclinganjo...@gmail.com<mailto:thomasclinganjo...@gmail.com>> wrote: > > 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 > <thomasclinganjo...@gmail.com<mailto:thomasclinganjo...@gmail.com>> 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 <d...@waugh.com<mailto:d...@waugh.com>> 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 <d...@waugh.com<mailto:d...@waugh.com>> >>> 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 >>> <denis.i...@free.fr<mailto:denis.i...@free.fr>> 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 <denis.i...@free.fr<mailto:denis.i...@free.fr>> >>> Inviato: giovedì 18 gennaio 2024 19:25 >>> A: demarcog83 <demarco...@gmail.com<mailto:demarco...@gmail.com>> >>> Cc: sp...@ietf.org<mailto:sp...@ietf.org> >>> <sp...@ietf.org<mailto:sp...@ietf.org>>; Giuseppe De Marco >>> <gi.dema...@innovazione.gov.it<mailto:gi.dema...@innovazione.gov.it>>; >>> oauth <oauth@ietf.org<mailto:oauth@ietf.org>> >>> Oggetto: Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status >>> Attestations (typo) >>> >>> >>> Non si ricevono spesso messaggi di posta elettronica da >>> denis.i...@free.fr<mailto:denis.i...@free.fr>. Informazioni sul perché è >>> importante >>> >>> 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 >>> <denis.i...@free.fr<mailto:denis.i...@free.fr>> 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/ >>> >>> 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". >>> >>> 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=40gmx....@dmarc.ietf.org<mailto:40gmx....@dmarc.ietf.org>> >>> 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 <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> On >>> Behalf Of Orie Steele >>> Sent: Mittwoch, 17. Jänner 2024 19:07 >>> To: sp...@ietf.org<mailto:sp...@ietf.org> >>> Cc: oauth <oauth@ietf.org<mailto:oauth@ietf.org>> >>> 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 >>> >>> 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/ >>> >>> Is also relevant to this draft. >>> >>> I also learned that >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ >>> >>> 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://www.w3.org/ns/credentials/examples/v2"; >>> ], >>> "id": "http://university.example/credentials/1872";, >>> "type": ["VerifiableCredential", "ExampleAlumniCredential"], >>> ... >>> } >>> >>> The credential type in RDF becomes >>> "https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential"; >>> >>> 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";, >>> "given_name": "John", >>> "family_name": "Doe", >>> "email": "john...@example.com<mailto:john...@example.com>", >>> "phone_number": "+1-202-555-0101", >>> "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 >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org<mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
