Not sure if this is the place to discuss yet, let me know otherwise. What about using the recently published RFC9421 on HTTP message signatures to sign the API verbs and payloads, and use RSC to bind the signature issuer to resource holdership? This would bring us the best of both worlds, standard identity management via JWTs/Oauth2 AS _and_ proof of holdership via RPKI.
Carlos https://www.rfc-editor.org/rfc/rfc9421.html On Thu, 21 Mar 2024 at 07:48, Job Snijders <[email protected]> wrote: > Thanks Tom! > > Looks like it was a good meeting. > > I’ll wait for a next revision before issuing the call for the working > group adoption. > > Kind regards, > > Job > Co-chair GROW > > On Thu, 21 Mar 2024 at 16:41, Tom Strickx <tstrickx= > [email protected]> wrote: > >> Dear grow members, please find the minutes of the Peering API side >> meeting below: >> >> Attendees: Aussie Broadband, Amazon, Workonline, Huawei, APNIC, Telstra, >> Meta, Cloudflare (12 attendees) >> >> 1. Brief walkthrough of PeeringAPI. >> 2. Open questions: PNIs: who issues LOAs, who orders XCs, exchanging >> preferences (redundant links, who unfilters first, ...). PeeringDB is not >> good enough. RPKI signed checklists could be worth it. Provisioning Finite >> State Machine. >> >> 3. Work with Peering Manager to implement the API to advance adoption. >> 4. Aussie agrees this is a good idea. Great for an eyeball network. >> Reduces complexity, single pane of glass. >> 5. 2 Types of business logic: peering logic and business logic that goes >> in the provisioning. The second one is what needs modelling. >> 6. IXP Manager integration? >> 7. Are there any additional security considerations? >> 8. Ben Maddison explains RSC. Signatures over arbitrary blobs of data. >> Rough workflow: each party issues a challenge. Sign the challenge. Provide >> signed blob back over the API (inband). >> PeeringDB is good enough for now, but baking it into the protocol as a >> first-class citizen might be a mistake. Make RSC a first-class citizen, and >> machine-to-machine OATH as a fallback. Similar to the key negotiation >> within SSH: Offer list of IdPs, receive list of IdPs. Ordering is not >> important, as long as you pick an IdP that is trusted. No need to use the >> same IdP in both directions. >> 9. Don't roundtable the FSM. Might need a workflow negotiation system. >> Might be good to communicate operational state. Get a feedback loop going. >> 2 classes of state transition: 1 that requires coordination, 1 that >> doesn't. To what extent do we expose "hygiene" of turnup testing. Protocol >> coordination will need to happen for ordering-of-actions. Might need a >> deadlock state. >> What are the preferences we should care about? Provide a human address >> for "escalation" in case of deadlock. >> Tie-break decision algorithms? >> Make the errors more expressive, but structured text. ENUM for the most >> frequent ones, but allow extendability. Look to YANG? >> Allow for resumption through the FSM once deadlocks have been resolved. >> If data-leaf is not provided, block state transition, and progress once >> that's there. Coordinated data-collection exercise. >> Route-server sessions? >> >> Next steps: We'll work on adding a section on the RSC challenge-response >> proposed authorization and authentication workflow. Work will also start on >> a minimal provisioning FSM. We want to thank all the contributors of >> today's meeting, and look forward to working with the Working Group in >> advancing this draft. >> >> -- >> Tom Strickx >> Principal Network Engineer >> AS13335 - Cloudflare >> _______________________________________________ >> GROW mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/grow >> > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
