Inline: On Fri, Sep 29, 2023 at 12:05 PM Brian Campbell <bcampb...@pingidentity.com> wrote:
> > If I might offer an observation... > > The draft-looker-oauth-jwt-cwt-status-list draft is (or can easily be[*]) > really just a generic status/revocation checking mechanism for JWTs in > general. Given the history/lineage of JWT development within the OAuth WG, > it seems like a general JWT status/revocation mechanism would fall easily > within the remit of the WG as is. > I agree with this. > > It seems to me as though the prospect of the formation of a new WG from > the potential SPICE BoF that may or may not be a suitable future forum for > the status list work has unintentionally delayed or diverted > attention around consideration of the status list work being adopted and > progressed in OAuth in the more near term. > > Speaking as a contributor to SPICE BoF, this was certainly never my intention. I don't think work should be delayed if it is well solved within an existing working group, and I agree that status lists are relevant to JWT and CWT generally, not just credentials. > > [*] it has some open TODOs for CWT based representations but no actual > content as such, which could be removed to focus the scope of the draft. > > +1 > > > On Tue, Sep 19, 2023 at 1:56 PM Orie Steele <orie@transmute.industries> > wrote: > >> Excellent. >> >> Inline: >> >> On Tue, Sep 19, 2023 at 2:12 PM <tors...@lodderstedt.net> wrote: >> >>> Hi Orie, >>> >>> best regards, >>> Torsten. >>> Am 18. Sept. 2023, 16:01 +0200 schrieb Orie Steele >>> <orie@transmute.industries>: >>> >>> Torsten, >>> >>> Thanks for sharing this excellent framing. >>> >>> I agree with everything you said. >>> >>> Please correct me if I'm wrong about anything in this summary: >>> >>> 1. Keep working on JWT based credential formats at OAuth (implicit, >>> don't expand OAuth charter to work on CWT credential formats ?) >>> >>> yes >>> >>> 2. If a new working group (SPICE) is formed focused on credentials, >>> authors are open moving credential specific work items there, and don't >>> plan new credential related items at OAuth. >>> >>> We are open to move the credential work to a new working group. We are >>> open to discuss whether that will be SPICE, so far it seems to be COSE >>> centric. It’s clearly in everyone’s interest to have the JSON and COSE >>> based credential formats aligned. >>> >> >> I agree, I think a big part of this comes from trying to respect the work >> that has already happened, in JSON-LD at W3C and JSON / JOSE at OAuth and >> OIDF. >> >> >>> 3. Coordinate with CBOR based credential formats (wherever they may be) >>> to ensure that architecture and conventions are as aligned as possible >>> >>> yes >>> >>> >>> Happy to help however I can, regardless of where work items land. >>> >>> Let’s talk about how we can bring the COSE and JSON credential work >>> together. >>> >>> >> Awesome, I think the most impactful way to achieve this would be adding a >> sentence like this to the SPICE BoF request, something to the effect of: >> >> The following documents would be transitioned from OAuth to SPICE if the >> WG forming BoF is successful. >> >> - draft-ietf-oauth-sd-jwt-vc >> - draft-looker-oauth-jwt-cwt-status-list >> >> It's debatable if the status list work item should move, since I see that >> as a generic token format that has applications beyond credentials. >> >> However, if authors feel it should be paired with >> `draft-ietf-oauth-sd-jwt-vc` I can also see that argument. >> >> Speaking as one of the authors of >> https://datatracker.ietf.org/doc/draft-prorock-cose-sd-cwt/ >> >> We would prefer to leverage a CWT status list format for that work, so if >> we consider the following work items as all possible candidates for SPICE: >> >> - draft-looker-oauth-jwt-cwt-status-list >> - draft-prorock-cose-sd-cwt >> - draft-ietf-oauth-sd-jwt-vc (perhaps we can adjust this to apply to both >> SD-JWT and SD-CWT). >> >> I can see us getting more concentrated contribution and having an easier >> time maintaining architectural alignment. >> >> I think sd-jwt should stay at OAuth, I agree with Brian, it's nearly >> complete, and I am happy to help close the gap on any remaining issues with >> the document. >> >> I'm happy to make further updates regarding consolidating credential work >> items in SPICE, and reducing the load on OAUTH WG, but I look to authors >> and the OAUTH working group to confirm if they are ok with the SPICE BoF >> request commenting on their work in this way. >> >> Perhaps we can discuss briefly in the OAuth office hours tomorrow. >> >> >> >>> best regards, >>> Torsten. >>> >>> >>> Regards, >>> >>> OS >>> >>> On Mon, Sep 18, 2023 at 7:06 AM <torsten= >>> 40lodderstedt....@dmarc.ietf.org >>> <https://mailto:40lodderstedt....@dmarc.ietf.org>> wrote: >>> >>> Hi Roman, >>> >>> I’m writing this post on behalf of the group of co-authors who proposed >>> the following drafts for adoption by the OAuth WG: >>> >>> draft-ietf-oauth-attestation-based-client-auth >>> draft-ietf-oauth-sd-jwt-vc >>> draft-looker-oauth-jwt-cwt-status-list >>> >>> We have brought these drafts to the IETF because they are built on IETF >>> drafts/standards and enhance them. Those drafts are interrelated and part >>> of a bigger effort to provide initiatives around the globe for building >>> ecosystems based on the Issuer/Holder/Verifier model, especially focussing >>> on EU’s eIDAS, with interoperable technical standards. >>> >>> The work is based on two pillars, Selective Disclosure JWT (SD-JWT) and >>> OpenID for Verifiable Credentials (OID4VC). The latter is a credential >>> format agnostic family of protocols for issuing and presenting verifiable >>> credentials and authenticating users based on keys in the wallet. These >>> specifications are being standardized at the OpenID Foundation; they are >>> already referenced by the eIDAS Architecture and Reference Framework. >>> >>> SD-JWT and OID4VC are combined in a specification designated as “OpenID >>> for Verifiable Credentials High Assurance Interoperability Profile with >>> SD-JWT VC” (HAIP). HAIP instantiates OID4VC with the credential format >>> SD-JWT VC to allow implementers to build truly interoperable systems. This >>> is the contribution we intend to make to eIDAS. >>> >>> While working on HAIP we identified missing pieces in the overall >>> picture, most notably a way to use well-established JWT content rules and >>> its extensibility model as basis for representing Verifiable Credentials >>> with JSON payload. That’s why we drafted draft-ietf-oauth-sd-jwt-vc. >>> >>> We also noticed Verifiable Credentials are typically long living >>> credentials and thus need a way for its issuer to influence its status. >>> That’s why we drafted draft-looker-oauth-jwt-cwt-status-list and >>> incorporated it into draft-ietf-oauth-sd-jwt-vc. >>> >>> In addition, we learned while working with the eIDAS expert group and >>> others that wallet to issuer authentication needs to fulfill very special >>> requirements. That’s why we drafted >>> draft-ietf-oauth-attestation-based-client-auth as a new client >>> authentication method. >>> >>> To sum up, draft-ietf-oauth-sd-jwt-vc and >>> draft-looker-oauth-jwt-cwt-status-list extend the work being done around >>> SD-JWT so we feel the OAuth WG is the best place to evolved them. However, >>> we are open to discuss to carve out the work around credential formats and >>> supporting mechanisms into a new working group. >>> >>> draft-ietf-oauth-attestation-based-client-auth is an OAuth extension, so >>> we believe it belongs to the OAuth WG. >>> >>> ** What's the body of work around SD/JWT/VC that should be done and how >>> much work will that be? What needs to be done first? >>> >>> draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list >>> are fundamental building blocks on the level of credential formats for >>> building applications according to the Issuer/Holder/Verifier model. A lot >>> of initiatives around the globe are looking for technical standards for >>> this kind of application now. (For example, the eIDAS expert group hopes to >>> finalize its Architectural Reference Framework (ARF) this year.) So there >>> is a window of opportunity for IETF and this group to make an impact with >>> solid, secure and usable technical standards. >>> >>> We don’t plan further contributions in this space to the WG beyond the >>> proposed drafts. >>> >>> ** What unknown about the direction and needed tasks? >>> >>> I hope I could shed some light on our plans. >>> >>> ** For whatever that work might be, how should the OAuth charter evolve >>> to support the work? >>> >>> We suggest extending the charter to cover work on credential formats and >>> related mechanisms based on JWTs. As already mentioned above, we are also >>> open to moving this work into a new dedicated working group once such a >>> working group is operational. That working group might be established as a >>> result of the SPICE effort. It would be good to coordinate closely with >>> those developing CBOR-based credentials to keep that work and ours >>> architecturally aligned. We, however, see the need to keep working on the >>> drafts to meet the expectations of current and prospect implementers. >>> >>> ** Is there work to be done around bridging the architectural narrative >>> used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model >>> (issuer, holder, verifier) used in >>> draft-ietf-oauth-selective-disclosure-jwt? >>> >>> We suggest clearly distinguishing protocol aspects from data format >>> aspects. draft-ietf-oauth-selective-disclosure-jwt as part of the >>> credential format aspect has dependencies on JWT but no dependencies on RFC >>> 6749. >>> >>> There is work to be done to cater for protocols sitting on top of OAuth >>> for supporting the issuer/holder/verifier model. OpenID4VC is built on top >>> of OAuth and we have come up with some observations around that. For >>> example, clients (either verifiers or wallets acting as clients towards >>> issuers) are typically not managed by the AS. Either there is a 3rd party >>> that the AS relies on for that purpose, or the client starts interacting >>> without any pre-established relationship. Also, in a wallet world, we see >>> the need to allow an app on the phone to securely authenticate towards an >>> AS, which requires key bound assertions. >>> draft-ietf-oauth-attestation-based-client-auth is our proposal to cope with >>> those issues. >>> >>> best regards, >>> Torsten. >>> Am 8. Sept. 2023, 21:07 +0200 schrieb Roman Danyliw <r...@cert.org >>> <https://mailto:r...@cert.org>>: >>> >>> Hi! >>> >>> We've observed growing energy around JWT, selective disclosure and VC >>> related topics in the WG in recent meetings. We spent almost all of the >>> third OAuth meeting at IETF 117 on related topics. The initial SD-JWT >>> (draft-ietf-oauth-selective-disclosure-jwt) has been followed up with >>> SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). There is also work like >>> draft-looker-oauth-jwt-cwt-status-list being proposed. >>> >>> As promised at IETF 117, we would like to start a conversation about the >>> direction the WG would like to take at a strategic level rather than >>> continuing to deal this topic in one document increments of additional >>> scope. >>> >>> ** What's the body of work around SD/JWT/VC that should be done and how >>> much work will that be? What needs to be done first? What unknown about the >>> direction and needed tasks? >>> >>> ** For whatever that work might be, how should the OAuth charter evolve >>> to support the work? >>> >>> ** Is there work to be done around bridging the architectural narrative >>> used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model >>> (issuer, holder, verifier) used in >>> draft-ietf-oauth-selective-disclosure-jwt? >>> >>> Thanks, >>> Roman, Hannes, and Rifaat >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <https://mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <https://mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> >>> *ORIE STEELE*Chief Technology Officerwww.transmute.industries >>> <https://transmute.industries> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> -- >> >> >> ORIE STEELE >> Chief Technology Officer >> www.transmute.industries >> >> <https://transmute.industries> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
