Inline: On Thu, Oct 13, 2022 at 8:26 AM AJITOMI Daisuke <[email protected]> wrote:
> > Hope you can make the call today. > > Sorry, it was too hard for me to attend the meeting at 2am JST. > > I don't know what kind of discussion took place at the BoF last night, but > let me add a few things: > > I knew that the SD-JWT was out of scope so I was not going to object to > the reopening of the WG because of the concerns about the SD-JWT. > > I said that I had no capacity to disagree with the adoption because I > don't know JWP well. However, if many other people say that the JWP depends > strongly on the Issuer-Holder-Verifier model, then I must disagree with the > adoption, as well as JD-JWT. > > I believe that the specification that can encourage unauthorized data > disclosure should not be standardized by the IETF. > The key here is that the disclosure IS authorized, by the data holder... they are the one that chooses to disclose... Similar to how the DMV does not control your ability to present your driver's license to 3rd parties. Issuer's don't control data in the 3 party system, after the holder has the credential, the holder can choose to disclose what they have / can prove, based on what the issuer has allowed. The only control the issuer retains is revocation, or expiration. OS > > Best regards, > Daisuke > > 2022年10月12日(水) 23:09 John Bradley <[email protected]>: > >> Thanks for the response. >> >> JWT—SD is not part of this proposed work. >> >> We are aware of that work and the proposed charter notes that liaison >> will happen between the groups. >> >> Hope you can make the call today. >> >> John B. >> >> Sent from my iPhone >> >> On Oct 12, 2022, at 4:48 AM, AJITOMI Daisuke <[email protected]> wrote: >> >> >> >>> However that seems to be a bit out of scope for the topic at hand. >> >> >> You are right, I was only pointing out that the higher level protocols >> using JWP/SD-JWT, which are based on the Issuer-Holder-Verifier model, have >> fundamental problems. In fact, the I-H-V model itself is the problem though. >> >> Anyway, since SD-JWT seems to assume only the I-H-V model, I must >> strongly oppose proceeding with this standard as is. >> >> On the other hand, I cannot judge whether JWP is based on only the I-H-V >> model. At least I cannot prove that it depends on the I-H-V model. >> ...I don't know what I am talking about, but using JWP may make the >> implementation of predicate-based disclosure easier, etc. >> >> > Is there a concrete argument for not allowing JOSE to be adapted to >> support the new algorithms? >> >> Thus, I cannot disagree with the adoption, at least from my perspective >> in this thread. >> >> If I could make one request, I would like to see the JOSE WG reopened >> instead of creating a new JWP WG. >> >> Best regards, >> Daisuke >> >> 2022年10月12日(水) 1:23 John Bradley <[email protected]>: >> >>> This is an interesting discussion on how higher level protocols might >>> use this work. However that seems to be a bit out of scope for the topic at >>> hand. >>> >>> The decision to be made is if modifications to the existing JOSE >>> container formats are needed to support the newer privacy-preserving >>> signature algorithms that will be approved by the CFRG. >>> >>> I guess a legitimate position might be that the new algorithms somehow >>> damage privacy or security, so JOSE should not support algorithms approved >>> by the CFRG. >>> >>> People on the list argue that higher-level protocols would benefit from >>> support for these algorithms like BBS+ in JOSE. >>> >>> So there seems to be demand. >>> >>> Is there a concrete argument for not allowing JOSE to be adapted to >>> support the new algorithms? >>> >>> Remember the workgroup we are talking about chartering is neither >>> approving the individual algorithms nor defining the legal policy structure >>> for how there use in the EU. This is simply a container format exercise. >>> >>> >>> I hope the Virtual BOF tomorrow can answer if this work needs to be done >>> and if there are people interested in doing it. >>> >>> >>> Regards >>> John B. >>> >>> >>> >>> >>> >>> On Oct 11, 2022, at 5:58 AM, Orie Steele <[email protected]> >>> wrote: >>> >>> > the Issuer must be involved in the disclosure process, >>> >>> This is exactly the kind of privacy issue the 3 party system is trying >>> to improve on. >>> >>> I don't need the department of motor vehicles with me, when I prove my >>> age to buy an age restricted beverage. >>> >>> I don't need their permission to disclose my age, from a credential they >>> issued.... they should not know what they don't need to know. >>> >>> The issuer is a data controller. >>> >>> The holder is often both a data controller and a data subject. >>> >>> > providing a data disclosure API like userinfo by the Issuer >>> >>> I don't agree that providing an API is more reasonable than providing a >>> data format that supports disclosure. (JWP, SD-JWT, Merkle Proofs, various >>> ZK formats including snarks, starks, etc...) >>> >>> That being said, I have built such an HTTP based API for BBS+ Linked >>> Data Proofs, where a subset of an RDF graph is obtained from the issuer's >>> signature over the original RDF graph. >>> >>> https://w3c-ccg.github.io/vc-api/#derive-credential >>> >>> warning this is all fairly old, before the work moved to CFRG: >>> https://w3c-ccg.github.io/ldp-bbs2020/ >>> >>> The query format (uses JSON-LD Frame): >>> https://w3c-ccg.github.io/vp-request-spec/#query-by-frame (alternative >>> https://identity.foundation/waci-didcomm/v1.0/#deterministic-rendering-of-the-json-ld-frame-object >>> ) >>> >>> >>> https://github.com/transmute-industries/verifiable-data/tree/main/packages/bbs-bls12381-signature-2020 >>> >>> ^ The signature format has since been changed, and there is code rot >>> here now. >>> >>> Having the issuer present in all presentations made by a holder >>> essentially removes the autonomy of the holder... it defeats the value of >>> the 3 party system (which might not be the right system for all use cases >>> anyway). >>> >>> It's also related to these sections: >>> >>> - https://www.w3.org/TR/vc-data-model/#subject-holder-relationships >>> - >>> https://www.w3.org/TR/vc-data-model/#holder-acts-on-behalf-of-the-subject >>> >>> Regards, >>> >>> OS >>> >>> >>> On Mon, Oct 10, 2022 at 2:45 PM AJITOMI Daisuke <[email protected]> >>> wrote: >>> >>>> Hi Torsten, >>>> >>>> >>>>> The issuer is not involved (and perhaps wouldn’t even know the >>>>> verifier). >>>>> >>>> >>>> From the Issuer's perspective, this is simply "unauthorized >>>> disclosure”, right? >>>> The personal data handled in a system based on the >>>> Issuer-Holder-Verifier model is supplied by the issuer and the Issuer >>>> should still be the data controller. >>>> Could you please tell me on what basis such unauthorized disclosure is >>>> allowed? >>>> As I said in my email to David, I believe that the Holder can only be a >>>> proxy of the Issuer (a.k.a. data processor on GDPR) on the >>>> Issuer-Holder-Verifier model. >>>> >>>> Let me ask one additional question. >>>> In the digital driver license system, an Issuer is a driver license >>>> issuing and management service and a Verifier is a digital driver license >>>> reader app. Obviously it would be more natural for the Verifier to be the >>>> Issuer's RP but why does the Verifier need to be the wallet's RP and not >>>> the Issuer's RP? What exactly is the wallet in this example? >>>> >>>> I don’t understand how you came to that conclusion. Can you please >>>>> explain? >>>>> >>>> >>>> Regarding case a), it is because, from my perspective that the Issuer >>>> must fulfill the responsibilities of the data controller even in the >>>> Issuer-Holder-Verifier model, the Issuer must be involved in the disclosure >>>> process, and providing a data disclosure API like userinfo by the Issuer >>>> (such as my counter proposal) is much more reasonable way than SD-JWT or >>>> JWP. >>>> Regarding case b), I think the reason is obvious. >>>> >>>> Best regards, >>>> Daisuke >>>> >>>> 2022年10月10日(月) 21:24 Torsten Lodderstedt <[email protected]>: >>>> >>>>> Hi Daisuke, >>>>> >>>>> Am 10.10.2022 um 05:41 schrieb AJITOMI Daisuke <[email protected]>: >>>>> >>>>> Hi Torsten, >>>>> >>>>> Thank you very much for your response in detail and sorry for taking >>>>> your time. >>>>> >>>>> First, I realized I had made a big mistake. I had assumed that the >>>>> Holder was supposed to show the QR code to the Verifier, but it was quite >>>>> the opposite! >>>>> >>>>> In our design, we use the QR Code to render a request for credential >>>>>> presentation, which is scanned by the holder with the wallet app. This >>>>>> request is authenticated with a signature based on the verifier’s key >>>>>> material. After successful authentication, authorization, and consent the >>>>>> wallet sends the data to a HTTP endpoint to the verifier. >>>>>> >>>>> >>>>> > the wallet sends the data to a HTTP endpoint to the verifier. >>>>> >>>>> Well..., do you mean that the wallet must be online in your design? >>>>> >>>>> >>>>> That or the transaction is performed via BLE or NFC. >>>>> >>>>> >>>>> Anyway, in your design, I am assuming that each time the wallet >>>>> discloses the Holder's claims to the Verifier, it must pass the Verifier's >>>>> client_id to the issuer to get the verifier's public key for the >>>>> validation >>>>> of the signature >>>>> >>>>> >>>>> Nope. In this model, the wallet is an OAuth AS. So the authentication >>>>> happens between verifier and wallet. The issuer is not involved (and >>>>> perhaps wouldn’t even know the verifier). >>>>> >>>>> , or pass the client_id and the public key to check if it is valid, is >>>>> this correct? In any OAuth flow, client authentication and authorization >>>>> is >>>>> performed (or at least the validity of the client_id is checked) before >>>>> issuing the token. We can assume that the same level of security is >>>>> provided, correct? Since both the wallet and the Issuer are online. >>>>> >>>>> > the wallet sends the data to a HTTP endpoint to the verifier. >>>>> >>>>> At the very least, I have found that the Verifier must also be online >>>>> and have Web-PKI server cert and serve a HTTPS endpoint. And I have also >>>>> found the wallet (the holder) must leave access logs in the Verifier that >>>>> it does not originally need to leave at all, along with its user agent >>>>> information. >>>>> >>>>> > I agree, it’s basically the Holder that is offline. >>>>> >>>>> But in your design, the issuer, wallet, and verifier must all be >>>>> online, right? Nevertheless, from my perspective that the Holder is merely >>>>> a proxy for the Issuer, >>>>> >>>>> >>>>> I think that’s the difference between our mental models. As stated >>>>> above, the wallet is an OAuth AS itself and does not need to interact with >>>>> the issuer - at least this is one of the benefits of issuing SD-JWTs in >>>>> advance and using it multiple times in comparison to a on-demand JWT >>>>> issuance. >>>>> >>>>> the Issuer cannot prove that the holder has consented to the personal >>>>> data disclosure, including the content of that consent. >>>>> >>>>> >>>>> It doesn’t need to. >>>>> >>>>> >>>>> If all components are online, why can't a simple solution be adopted >>>>> where the issuer provides an endpoint (like /userinfo) for selective >>>>> disclosure? >>>>> Do you really need SD-JWT? I'd like you to consider this in comparison >>>>> to my counter proposal. >>>>> >>>>> Excellent question! I’m not a lawyer (and this a legal question). What >>>>>>> I assume is >>>>>>> a) either the wallet provider acts on behalf of the issuer under a >>>>>>> data processing agreement or >>>>>>> b) the wallet provider becomes another data controller after the >>>>>>> user consented with the transfer of the credential to the wallet. >>>>>>> >>>>>> >>>>>> This question is not from a lawyer's perspective but from the >>>>>> perspective of an engineer/operator who has to manage personal data >>>>>> though. >>>>>> I have a lot to say in response to this answer of yours, but I would >>>>>> appreciate it if you could answer the above questions first. >>>>>> >>>>>> >>>>>> Look forward to see your follow up questions. >>>>>> >>>>> >>>>> I wrote most of what I wanted to say in my reply to David but, >>>>> >>>>> I think that the Holder can only be the "data processor" (acting on >>>>>> behalf of the controller) in the Issuer-Holder-Verifier model because the >>>>>> Holder's personal data was designed and created by the Issuer for its own >>>>>> service and clearly belongs to the Issuer as the data controller. "If >>>>>> issuance is just handing the subject of the information their data back", >>>>>> the Issuer should get the Holder's (user's) consent to process the data >>>>>> but >>>>>> it is not mandatory in GDPR. I think this fact is one of the proofs that >>>>>> the personal data belongs to the data controller under GDPR. >>>>>> >>>>> >>>>> This is case a). >>>>> >>>>> That might mean the wallet becomes a new “data controller” if it is >>>>>>> hosted software. >>>>>>> >>>>>> >>>>>> Yes, of course, through some delegation process, the wallet (wallet >>>>>> provider) could be a data controller. But in this case, the wallet should >>>>>> be regarded as an Issuer (IdP). I believe that this should not be >>>>>> considered an Issuer-Holder-Verifier model, but rather an existing >>>>>> 2-party >>>>>> model (IdP-RP) with the original Issuer decoupled. >>>>>> >>>>> >>>>> And this is case b). >>>>> >>>>> In case a) the Holder must act on behalf of the Issuer (and thus >>>>> fulfill various data controller responsibilities), while in case b) the >>>>> original Issuer should be decoupled. In both cases, the understanding is >>>>> that the JWP/SD-JWT are not helpful. >>>>> >>>>> >>>>> I don’t understand how you came to that conclusion. Can you please >>>>> explain? >>>>> >>>>> best regards, >>>>> Torsten. >>>>> >>>>> >>>>> Best regards, >>>>> Daisuke >>>>> >>>>> >>>>> 2022年10月9日(日) 17:11 Torsten Lodderstedt <[email protected]>: >>>>> >>>>>> Hi Daisuke, >>>>>> >>>>>> Am 08.10.2022 um 23:31 schrieb AJITOMI Daisuke <[email protected]>: >>>>>> >>>>>> >>>>>> Hi Torsten, >>>>>> >>>>>> Thanks for your quick response. >>>>>> >>>>>> Verifier authentication and authorization is the task of the wallet >>>>>>> (on behalf of the holder). How authentication/authorization is performed >>>>>>> depends on the protocol for credential presentation. In case of OpenID 4 >>>>>>> Verifiable Presentations (which is OAuth based), the verifier is >>>>>>> identified >>>>>>> via its client id and authenticated using one of the various OAuth >>>>>>> mechanisms. >>>>>>> >>>>>> >>>>>> I just want to understand correctly what you are talking about, so >>>>>> could you please answer me more specifically by using a specific use case >>>>>> (QR-code)? >>>>>> >>>>>> In the use case where a Holder discloses some claims as a SD-JWT to a >>>>>> Verifier via QR code, is there any way to prevent or mitigate disclosure >>>>>> by >>>>>> mistake if the Verifier is malicious? I'd like to know a specific way for >>>>>> the wallet (on behalf of the Holder) to confirm the validity of the >>>>>> Verifier before showing the QR code. >>>>>> ... or is the QR-code use case out of scope? >>>>>> >>>>>> >>>>>> QR Codes can be used in various different ways. In our design, we use >>>>>> the QR Code to render a request for credential presentation, which is >>>>>> scanned by the holder with the wallet app. This request is authenticated >>>>>> with a signature based on the verifier’s key material. After successful >>>>>> authentication, authorization, and consent the wallet sends the data to a >>>>>> HTTP endpoint to the verifier. >>>>>> >>>>>> >>>>>> As I mentioned in the previous post, I believe that in the selective >>>>>> disclosure transaction on the Issuer-Holder-Verifier model, only a Holder >>>>>> can be offline, while an Issuer and a Verifier must be online (the >>>>>> Verifier >>>>>> must be able to access the Issuer), is this understanding correct? If it >>>>>> is >>>>>> not correct, again, I'd like to know a specific way by which the Holder >>>>>> confirms the validity of the Verifier before the disclosure, without the >>>>>> communication between the Verifier and the Issuer. >>>>>> >>>>>> >>>>>> I agree, it’s basically the Holder that is offline. The degree of >>>>>> Internet connectivity needed on the Verifier end varies between use >>>>>> cases. >>>>>> >>>>>> The cryptographic validity of the credential can typically be >>>>>> validated with the credential presentation alone. There might be some DLT >>>>>> based approaches requiring access to the actual key material associated >>>>>> with a DID. With raw public keys or certs, this isn’t the case. >>>>>> >>>>>> Whether the credential was issued by a trusted issuer requires >>>>>> additional data, might be the issuer‘s public key as trust anchor or some >>>>>> kind of trust chain. This data can be cached or configured. >>>>>> >>>>>> If the credential can be revoked by the issuer, the verifier also >>>>>> needs to access revocation data. Whether this data can be cached depends >>>>>> on >>>>>> the revocation policy, i.e. how long it is acceptable until a change is >>>>>> put >>>>>> into effect. Whether the verifier needs to communicate with the issuer >>>>>> depends on the mechanism. OCSP alike mechanisms would require it. All >>>>>> other >>>>>> mechanisms I‘m familiar with can also be hosted someplace else. >>>>>> >>>>>> >>>>>> Excellent question! I’m not a lawyer (and this a legal question). >>>>>>> What I assume is >>>>>>> a) either the wallet provider acts on behalf of the issuer under a >>>>>>> data processing agreement or >>>>>>> b) the wallet provider becomes another data controller after the >>>>>>> user consented with the transfer of the credential to the wallet. >>>>>>> >>>>>> >>>>>> This question is not from a lawyer's perspective but from the >>>>>> perspective of an engineer/operator who has to manage personal data >>>>>> though. >>>>>> I have a lot to say in response to this answer of yours, but I would >>>>>> appreciate it if you could answer the above questions first. >>>>>> >>>>>> >>>>>> Look forward to see your follow up questions. >>>>>> >>>>>> best regards, >>>>>> Torsten. >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Daisuke >>>>>> >>>>>> 2022年10月8日(土) 18:24 Torsten Lodderstedt <[email protected]>: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> > Am 08.10.2022 um 08:26 schrieb AJITOMI Daisuke <[email protected] >>>>>>> >: >>>>>>> > >>>>>>> > >>>>>>> > Hi folks, >>>>>>> > >>>>>>> > I could be making a big mistake but I don't really understand the >>>>>>> need for JWP or SD-JWT. >>>>>>> > >>>>>>> > Let me ask two questions about the Issuer-Holder-Verifier model >>>>>>> that JWP and SD-JWT are premised on. >>>>>>> > >>>>>>> > 1. How does a Holder confirm the validity of a Verifier before the >>>>>>> selective disclosure? >>>>>>> > >>>>>>> > In the typical use case where a Holder selectively discloses some >>>>>>> claims to a Verifier using a QR code or NFC, is there any way to >>>>>>> prevent or >>>>>>> mitigate disclosure by mistake if the Verifier is malicious or infected >>>>>>> with malware? It is impossible for a user to visually determine whether >>>>>>> the >>>>>>> QR code reader device (or app) is malicious or not. >>>>>>> > >>>>>>> > In order to confirm the validity of the Verifier (as in the >>>>>>> general OAuth flow), I suppose that the Verifier must be authenticated >>>>>>> by >>>>>>> the Issuer each time before the Holder's claims are disclosed. At >>>>>>> least, it >>>>>>> looks to me that SD-JWT is a dangerous solution because it discloses >>>>>>> linkable personal data without any Verifier validation. >>>>>>> >>>>>>> It is important to notice that in the verifier/holder/issuer (aka >>>>>>> Verifiable Credentials model aka decentralized identity model) the >>>>>>> issuer >>>>>>> needs to rely on the wallet (provider) to handle the credential/claims >>>>>>> disclosure properly. The issuer should therefore validate the wallet and >>>>>>> its security and privacy mechanisms before issuing a credential. >>>>>>> >>>>>>> Verifier authentication and authorization is the task of the wallet >>>>>>> (on behalf of the holder). How authentication/authorization is performed >>>>>>> depends on the protocol for credential presentation. In case of OpenID 4 >>>>>>> Verifiable Presentations (which is OAuth based), the verifier is >>>>>>> identified >>>>>>> via its client id and authenticated using one of the various OAuth >>>>>>> mechanisms. >>>>>>> >>>>>>> > >>>>>>> > 2. How does an Issuer fulfill its responsibility as a personal >>>>>>> data controller? >>>>>>> >>>>>>> Excellent question! I’m not a lawyer (and this a legal question). >>>>>>> What I assume is >>>>>>> a) either the wallet provider acts on behalf of the issuer under a >>>>>>> data processing agreement or >>>>>>> b) the wallet provider becomes another data controller after the >>>>>>> user consented with the transfer of the credential to the wallet. >>>>>>> >>>>>>> best regards, >>>>>>> Torsten. >>>>>>> >>>>>>> > >>>>>>> > My understanding is that the Issuer is responsible for the >>>>>>> Holders' personal data management because the Issuer is providing >>>>>>> selective >>>>>>> disclosure of the personal data as a service. This means that the Issuer >>>>>>> can be regarded, for example, as a 'controller' as defined in GDPR. At >>>>>>> this >>>>>>> time, the Issuer has various responsibilities regarding the protection >>>>>>> of >>>>>>> the personal data. The following is a partial list: >>>>>>> > - Record and maintain logs of the data disclosures to third >>>>>>> parties (the Verifiers) for a certain period of time. >>>>>>> > - Notify a supervisory authority of the scope of impact and >>>>>>> countermeasures in the event of an incident, such as a personal data >>>>>>> breach. >>>>>>> > - Demonstrate that the Holder has consented to the disclosure of >>>>>>> his or her personal data. >>>>>>> > - etc. >>>>>>> > >>>>>>> > In this Issuer-Holder-Verifier model where an Issuer is not >>>>>>> necessarily involved in the disclosure transaction between a Holder and >>>>>>> a >>>>>>> Verifier, how does the Issuer fulfill the above responsibilities? I >>>>>>> suppose >>>>>>> that in order to preserve the audit log containing the Holder's consent >>>>>>> in >>>>>>> a manner that even the Holder cannot repudiate, the Issuer would have >>>>>>> to be >>>>>>> involved in the disclosure transaction each time, similar to question 1. >>>>>>> > >>>>>>> > I have seen some people say that it is a kind of privacy invasion >>>>>>> for an Issuer to be able to track every disclosure transaction by a >>>>>>> Holder, >>>>>>> but I think that is false. The Issuer is recording the transaction data >>>>>>> for >>>>>>> compliance with a legal obligation as a personal data controller, and >>>>>>> any >>>>>>> deviation from this should be prohibited by law. I think that preventing >>>>>>> data breach to malicious or compromised Verifier is much more privacy >>>>>>> protective. >>>>>>> > >>>>>>> > Anyway, my point is that in light of the obvious security measures >>>>>>> that an Issuer should take (Question 1) and the general personal data >>>>>>> protection legislation (Question 2), in the selective disclosure >>>>>>> transaction, only a Holder can be offline, while an Issuer and a >>>>>>> Verifier >>>>>>> have to be online. >>>>>>> > >>>>>>> > If this assumption is correct, then neither JWP nor SD-JWT is >>>>>>> necessary, and the solution to be adopted may vary greatly. >>>>>>> > >>>>>>> > For example, a solution where (1) a Holder generates and passes to >>>>>>> a Verifier an short-lived token indicating the user's consent to the >>>>>>> selective disclosure protected by end-to-end encryption between the >>>>>>> Issuer >>>>>>> and the Holder, and (2) the Issuer provides endpoints for the selective >>>>>>> disclosure that requires the short-lived token and Verifier >>>>>>> authentication >>>>>>> is simpler and more secure than JWP or SD-JWT. It is also more compliant >>>>>>> with a general personal data protection regulation. Furthermore, in the >>>>>>> end-to-end encryption, the Holder generally uses an ephemeral public >>>>>>> key so >>>>>>> the unlinkability of the disclosed claims is also achieved naturally. >>>>>>> > >>>>>>> > I would appreciate your feedback on the above. >>>>>>> > >>>>>>> > Sorry for the long post. >>>>>>> > >>>>>>> > Best regards, >>>>>>> > Ajitomi, Daisuke >>>>>>> > _______________________________________________ >>>>>>> > jose mailing list >>>>>>> > [email protected] >>>>>>> > https://www.ietf.org/mailman/listinfo/jose >>>>>>> >>>>>> >>>>> _______________________________________________ >>>> jose mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>> >>> >>> -- >>> *ORIE STEELE* >>> Chief Technical Officer >>> www.transmute.industries >>> >>> <https://www.transmute.industries/> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >>> >>> _______________________________________________ >>> jose mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/jose >>> >> _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
