- From: CCG Minutes Bot <minutes@w3c-ccg.org>
- Date: Wed, 13 Sep 2023 00:44:11 +0000
Thanks to Our Robot Overlords for scribing this week! The transcript for the call is now available here: https://w3c-ccg.github.io/meetings/2023-09-12/ Full text of the discussion follows for W3C archival purposes. Audio of the meeting is available at the following location: https://w3c-ccg.github.io/meetings/2023-09-12/audio.ogg ---------------------------------------------------------------- W3C CCG Weekly Teleconference Transcript for 2023-09-12 Agenda: https://www.w3.org/Search/Mail/Public/advanced_search?hdr-1-name=subject&hdr-1-query=%5BAGENDA&period_month=Sep&period_year=2023&index-grp=Public__FULL&index-type=t&type-index=public-credentials&resultsperpage=20&sortby=date Organizer: Mike Prorock, Kimberly Linson, Harrison Tang Scribe: Our Robot Overlords Present: Harrison Tang, Justin Richer, Greg Bernstein, Alan Karp, Wendy Seltzer, Erica Connell, Chandi Cumaranatunge, Mike Xu, Leo, Phil Long, Kimberly Linson, Kaliya Young, Sharon Leu, Jeff O - HumanOS, David I. Lehn, Gus Our Robot Overlords are scribing. Harrison_Tang: So welcome to this week's at w3c shiji meeting today we are very excited to have Justin returned from be scope bespoke engineering to actually present and lead a discussion on machine identity and Federated systems so Justin previously has worked on all off quite a bit including all us Dynamic claimed registration token expect introspection but most recently he has worked on HGTV signatures. Harrison_Tang: connect with you. Harrison_Tang: Talk about in a few weeks later today we invited him to actually talk about his latest working machine identity in criteria systems because previously few weeks back we have a couple threads I would say two three threads around this topic but before we get to today's a main agenda just wanted to do a quick reminder on the code. Harrison_Tang: ethics and professional conduct. Harrison_Tang: Mainly just make sure that we are respectful to each other and acknowledge each other's perspectives. Harrison_Tang: A quick IP note anyone can participate in these calls however all substantial contributions to any ccg work items must be member of the ccg with for IPR agreement sign so if these equipments acronyms sounds over doubting and you have questions feel free to just paint any of the cultures including myself. Harrison_Tang: all right. <tallted> I am sad to miss this session live, due to TPAC conflict... I hope the recording works! Harrison_Tang: These meetings are being recorded and automatically transcribe we will publish these transcriptions basically in the next day the in the next few days at the latest we used to teach at to Q speakers during the call so type in Q + to add yourself to a queue if you have any questions I'll work you - to remove yourself to the queue. Harrison_Tang: Introductions and reintroductions if you are new to the community where you haven't been active and you want to re-engage with the community police feel free to just unmute and introduce yourself. Harrison_Tang: I see mostly familiar faces so right well at the end of the meeting if we got time feel free to just on you and introduce yourself at that time as well by announcements were reminders any announcements and reminders Korea please. Kaliya Young: And I believe coming up October 10 through 12 and I also wanted to flag another band that I've been working on with the open Wallet Foundation we're on the cusp of finally like a go to have to have an open Wallet Foundation meeting between 9 and. Kaliya Young: At 9 and like bun on Monday and I'm going to kind of curious people can sort of signal I don't know plus 1 and taught or something like if they are into like we're trying to gauge like is there actually Community interest and capability of coming to an event Monday morning so that's the open-loop foundation that Linux Foundation nests nest and I'd Linux Foundation that was founded about a year ago. Kaliya Young: So there is no 4. <phil_t3> When is the meeting - what Monday? Kaliya Young: A time to sort of saying it's almost like I saved the day time sharing so. Harrison_Tang: By the way Clea other major developments from Open Water Foundation but we will be interested to learn about because like if so then maybe we should invite them to kind of talk about it as W3 okay. Kaliya Young: Definitely you think by them to come and speak I Googled officially joined the foundation over the summer they sort of release it the quiet you know when no one would see it in the late August but there is some press release for that and there's been diluted contributions by I don't know how to say I think it's scented the farm worker what project there is I believe several SDG&E implementation. Kaliya Young: And from what I hear there's more code coming in the pipeline so. Kaliya Young: The current vision is to present the existing code and then with everybody who is present have a Converse you know a conversation class while facilitated by me brainstorm about what a while it ecosystem looks like to help them form how to proceed as an organization and open community. Harrison_Tang: Great cool I'll reach out and connect with them thanks. Harrison_Tang: Any other announcements where we minded. Kaliya Young: https://internetidentityworkshop.com/ Harrison_Tang: I just a quick preview of our agenda So today we're going to we're going to talk about machine identity and Factory systems next week we'll have Fido to and wipe off then so we have David wait to talk about that so that's more on the authentication front and then the week after that over Manu is going to talk about selective disclosure for data integrity and lastly we'll have Mike Jones. Harrison_Tang: Jones talking about. Harrison_Tang: Demonstrating proof of possession at the application layer so so that's what's coming in the next four weeks. Harrison_Tang: All right any updates on the work items or any questions on our guidance. Harrison_Tang: All right that's how I get to the net agenda so earlier I just gave a quick introduction to Justin return and yes we're quite a bit on the off side of things and most recently we connected with in regards to a good nap which you will present in the next three weeks but also he mentioned about machine identity in Federated systems work that he has been working on so. Harrison_Tang: which coincides with. Harrison_Tang: Conversation thread for a few weeks ago in regards to this topic of not just human identity personal identities but machine identity so without further Ado Justin the floor is yours. Justin Richer: Wonderful thank you for inviting me it's good to be back at the ccg I try to make these calls when I can my schedule doesn't often allow it can be sharing out a presentation so just give me a moment while that loads up. Harrison_Tang: Yep looks good. Justin Richer: All right I just need to I just want to confirm that that that is still sharing and you should be seeing the full screen of the slide is that is that what you guys are all right all right fantastic so hello everybody my name is Justin richer I know many of you from various standards work over the last couple of decades here and today I'm going to be talking about some new work that I've been getting involved with in the spiffy community and the ietf community. Justin Richer: And also you know how it touches. Justin Richer: Off and that is specifically around this concept of workload identity and and what that actually means so let's start with a really basic question what is a workload well one definition that I think fits really well is that it is a single piece of software deployed with a specific configuration for a single purpose so when you've got a piece of software that does exactly. Justin Richer: One thing. Justin Richer: Is that thing and you have it configured to only do that thing that's the type of thing that we're talking about for a workload so say that it is a assigning service it takes in the document it applies the signature and Returns the result right or on the other end a validation service that takes in a signed document manages pulling the keys validating the signature and Returns the result back to the system. Justin Richer: One of the important. Justin Richer: Things about workload especially today though is that you can have many many copies of these things are notion of what a computer is and what a server is today is pretty different from what it was 20 years ago or even 10 years ago and one of the key differentiations for this notion of what a workload is as opposed to what we might traditionally consider just a service or a server is that. Justin Richer: The whole idea with the workload is that they are repeatable that you can spin up a bunch of these and because they do a single thing you can make lots of copies when you need them get rid of the copies when you don't need them. Justin Richer: So fundamentally that's what we're talking about for work gloves. Justin Richer: So what does this have to do with identity we've got software it's running it's doing things that should be good enough. Justin Richer: Let's say we've actually got three different cloud services. Justin Richer: All of. Justin Richer: Is comprised comprised different workloads in the system when we spend these up we want to know which one is which and we want to know things like how do we get. Justin Richer: These in secrets into these systems I want to be able to tell the difference between the orange system the yellow system the green system. Justin Richer: Right I need to. Justin Richer: Able to know when the green system is running that it is in fact the green system I expected to have a particular configuration be. Justin Richer: Actions and that can help me make decisions about what I expected to be allowed to do. Justin Richer: So spiffy is a project of the cloud native Computing Foundation it's an open source project with a with a reference implementation instead of. Justin Richer: These standards in CNC f. Justin Richer: Basically the way that it works is that you run an agent in your environment where all of your workloads are running and when your workload wakes up the first time it calls the spiffy agent and says like hey here I am who am I. Justin Richer: Workloads are not pre-configured to really know their own identity they don't get pre-configured with a secret that lets them call this agent and then that gets them the right identity because then you have to answer the question well how do you get that secret into the system in the first place spiffy is really clever in how it stands up because when these agents make this query it can do all of this it can create. Justin Richer: Is it can generate certificates and Trust roots and keys and provision out the right ones to each of these systems. Justin Richer: By basically looking at the environment of the workload itself so it takes a look at the workload and it can do all sorts of things like you know which kubernetes node is this running on which you know what's the hash of the software that's running on this image you know whether it's Docker image layers or what have you you know what is the what is the runtime footprint look like of. Justin Richer: This there's all these things that we can look at. Justin Richer: Software to know that only certain things are supposed to be running in this place at a given time and so when we see all of those that's how we know which piece of software it is. Justin Richer: And like I mentioned this with the agent allows us to hand out the right keys to the right agents so we can now hand things like certificates and tokens and whatnot to for example the orange service that only the orange service gets and only things that look like the orange service gets so if I have thousands of copies of that orange service then they're all going to get the right keys so that they can do orange service kinds of things. Justin Richer: What do I mean by that well let's say. Justin Richer: Actually bundling our services together so the orange service needs to call the Yellow service which needs to call the green service. Justin Richer: Is really one of the core things that spiffy solves because each of these has their own identity and it's paired with cryptographic material the yellow service when it gets this call it knows that the orange service is making that call and likewise the green service knows that the yellow service is making that call and we can do this using Mutual TLS we can do this with there's current work to do a center constraint profile token profile. Justin Richer: Using oauth Style. Justin Richer: Inside of the workloads mutual TLS is the most common today by far but each of these nodes knows a little bit about the caller. Justin Richer: But this is also kind of where spiffy starts to fall over sideways a little bit so let's say I'm down here at the leaf surface down at the green note I want to know not only is it the yellow service that's calling me but I want to know that the orange service called the yellow service in order to call me I want to know that this call that's part of my workload propagated through the appropriate channels in the appropriate chain before it gets to me. Justin Richer: Teal TLS is hop by hop it doesn't tell us. Justin Richer: Connection information all tokens are meant to go in one side and you know kind of get passed through so that doesn't tell us this information this is this is kind of a gap and this is one of the spaces that some of the new work that I'm doing is starting to look at because we want to be able to answer more complex questions like this given this base model of we have a workload that gets and identity in a set of cryptographic. Justin Richer: Deal with it. Justin Richer: Do with that what kinds of questions can I answer. Justin Richer: And this gets more interesting when we actually start to label our stuff so let's say that The Orange Box is actually an API Gateway and it calls the Food Service which in turn depends on the bar service now the reason that we would set this up is that there's probably an external client out there somewhere that's calling our API. Justin Richer: And this presents an interesting security architecture problem because it's the client has the access rights but that leaf node is the one that has the data that the client wants so how do we even start to talk about propagating this kind of stuff well in the oauth world and similar protocols like good nap and and others. Justin Richer: We solve this. Justin Richer: By ignoring it we wrap all of that those workloads inside this concept called the resource server we abstract it and so 40 Watts purposes the resource server is a solid block the client doesn't care how its implemented and I would argue in most cases nor should the client actually care in those called the gateway and it knows that data comes out of the Gateway at some point and from the clients perspective. Justin Richer: That works great. Justin Richer: And this abstraction is actually super powerful because it allows us to answer higher order questions like we have a resource owner in an authorization server that allows delegation to the client software and we can even do some fancy tricks like having sender constrained access tokens so the client calling the resource server is the only piece of software that's allowed to use that client because it's been bound to a key that only the client has but the problem comes from the fact. Justin Richer: That inside we don't really know what's. Justin Richer: Which means that all of our assumptions from inside this bubble and outside this bubble start to fall over so let's take a look back at that Center constraint access token the client is the one presenting the token to the resource server but we need to get it all the way over to that leaf node in order for it to make sense because there's going to be information in that token or associated with that token that the leaf node needs to care about. Justin Richer: So what do we do. Justin Richer: The client is the only entity that can present that constrain token by Design we don't want other people to be able to present that token at least not outside of our workload chain but we definitely want the gateway to be able to pass that token along to the food server and the food server to pass it to the bar server but they're not bound to that token in the same way they don't even necessarily have access to the authorization server. Justin Richer: So how do we start to solve that problem. Justin Richer: And what's interesting is that in practice this is something that people run into when they're building out real systems in practice people solve this in a bunch of clever ways so in some systems they will strip off the sender constraints once you're inside this environment and just pretend that that incoming token really was just a bearer token all sometimes it'll get exchanged for a different internal token that only the internal Services can use some time. Justin Richer: Time's the external token gets wrapped inside of a new internal token there are other. Justin Richer: As well but none of these are really standard practices none of this is really defined by a document that says here's how you can solve this and here are the trade-offs that you need to consider when solving it in this particular way. Justin Richer: Not really clear with all of these patterns how we get this external information like who the resource owner was all the way down to that leaf node let's say that that leaf node is assigning service that food needs in order to fulfill the request well the leaf node needs to know who's Keys it should be using you know which escrowed keys are stored there that it should be using to sign the document to hand it back. Justin Richer: Back up. Justin Richer: To the client you know the food service in the Gateway service aren't going to have access to any of those keys but the bar surface it needs to know who that original resource owner is. Justin Richer: Mark that into the token but as we saw we might be rapping that token we might be changing that token for something else we need to have good patterns in good standards to be able to do that we don't have that in the community today we've got a lot of sort of interesting point Solutions. Justin Richer: For though that leaf node probably wants to know a lot more about the world we not only care about the resource owner we actually care that the token that I'm seeing did that come from an appropriate authorization server that I should be trusting did that come through the front door from a client that should have been able to present it and is the the chain that that made this request get to me is that standing up. Justin Richer: So in some systems will say you know what we will put this whole notion of which a.s. in which client and all of that will just code all of that into the gateway and then abstract that and send it down the chain that's great but then you really really really need to know that this Gateway did its job and was involved in the process of getting all the way down to this bar service even having just one node in the middle makes that a harder to describe and. Justin Richer: Harder to solve but it gets even weirder. Justin Richer: As in today's systems we're really not even talking about just deploying all of these little workload modules in a single Cloud environment anymore. Justin Richer: People are building out lots of interesting services that run across multiple different Cloud environments multiple different Cloud systems and so you can have something that goes all the way down the chain and at that point I need to go call a different API to fulfill this which means I'm now getting outside of our container environment in jumping inside a different container environment so when I get all the way down to that. Justin Richer: That quick. Justin Richer: Lower right hand corner how do I answer that this chain is actually valid like how can I even start to talk about the path which might not even be linear that this request went through on its way to me because that food service may have called something else and done some sort of side processing before it went to call the bar service and the quacks service that's on a different Cloud might actually really care about. Justin Richer: Sample that food service could be calling out on the side to an audit and compliance service and so by the time the request gets all the way down to that cooks node Cooks node need some assurance that yeah that really did go through or else it could be you know it could be us on the line. Justin Richer: But this. Justin Richer: Still when we start drilling into this because remember those external things that we've been kind of ignoring now the a.s. and the client well the truth is a lot of those probably have their own internal call chains as well their own internal workloads all depending on how you build and deploy systems and if I'm building out something that I really want to have an assurance about how things work we need to at least be able to talk about these things. Justin Richer: And there's a lot of times in this where yeah I might. Justin Richer: Abstract this and say that yes the client is valid. Justin Richer: But sometimes sometimes I need greater Insight so as I hope you can see the problems that people are seeing today go a lot further than just did the right user delegate to the right piece of software or is this token valid or even did the right instance of software get the right key when it booted up. Justin Richer: Ding and chaining these things together and you can build some amazing systems but you start to see the crack somewhere in between where the standards come together and that's that's the question that we recently took to the ietf. Justin Richer: Now the. Justin Richer: If you can. Justin Richer: He wrote wrote a book and coined this phrase that I love that spiffy is about solving the bottom Turtle so if you guys are unfamiliar with the phrase It's Turtles all the way down very roughly the world is perched and I'm butchering this but the world is perched on on the back of four elephants which stand upon for tortoises and somebody asked well what's underneath the tortoises and. Justin Richer: Well that's another tortoise and then it's. Justin Richer: All the way down to it's an infinite recursion philosophical problem. Justin Richer: Spiffy solves the boot keying issue in the boot identity issue for new software waking up in this environment so it solves that initial Turtle we can get keys to a piece of software fairly reliably. Justin Richer: So one of the questions that we brought to the ietf this summer was are there parts of this bottom Turtle problem that our that makes sense to address inside of the ietf but more importantly in my view is that once if we even assume that we can do that what are the question is is that allow us to ask are there other turtles in the stack that we can now care about and we can now talk about some. Justin Richer: Some of these questions like. Justin Richer: Back here like we don't even really have a good common vocabulary for talking about how these chains propagate how we talk about Assurance between these things how we identify the entities between these in a way that is consistent and actionable we need to really start that conversation. Justin Richer: So that's what we're starting to do there's a new mailing list in the ietf called wimzie workload identity in multi service environments and we are just getting started this was put together just before the ietf in San Francisco which was last month I think it's 20 23 times we were to makes no sense but at the last ietf meeting we put that together the list is there it is active. Justin Richer: And because this is an ietf. Justin Richer: You can anybody can join it it is a public list and I encourage you all to do so if any of this problem space or any of the potential solution space is interesting to you we're hoping to potentially get a new working group in the ietf to start working on some of these problems and we're starting out that process now. Justin Richer: And with that I will be happy to take questions and any conversations. Justin Richer: People might have. Harrison_Tang: I saw Justin I'm just curious is this similar to kind of the object capability security model like or like you know is analogous to that or is a little bit different. Justin Richer: So it's different so this isn't just about how you create a capability and propagate it through the system because a lot of times you don't actually want to be using pure capabilities you want to use stuff that is that is limited so that the security artifact can actually be. Justin Richer: The in in sort of the right right environments in the right places so this isn't trying but more fundamentally though to answer the question better this is not about trying to create a new security model this is about trying to model the security of these kinds of environments that we have that we didn't really have an analogue to previously. Harrison_Tang: Got it and then like what do you envision the business use cases are it is mostly just for kind of devops trying to understand their environment or like or maybe multi-cloud light environments that you just mentioned or hard that kind of business use case. Justin Richer: Yeah so that's some of the driving use cases that people have started out with but to me I think it goes It goes so much farther one of the things that actually got me interested in this was was not actually the workload identity itself but the kinds of things that we could do with with this type of Technology at a more macro scale so let's say for example I have. Justin Richer: I've got. Justin Richer: I've got a user that is logging into my system for the first time but I'm actually taking their identity in from somewhere else so let's say for example they did a Federated login or they presented a VC or something like that and when they do that I'm going to create an account in my system and you know what they've got a Fido token I can take that as a local authenticator and find that to that account and I'm good to go. Justin Richer: But I. Justin Richer: Then take and make that same user account available elsewhere I can I can be a sort of a federation proxy and make that available to someone else or I can issue that user Avicii that's rooted in my environment that they can go take elsewhere. Justin Richer: And when the users. Justin Richer: Up down there suddenly you've got a lot of the same types of questions that you can ask about where did this come from what kind of path did they take how can I prove that and how much does that mean to me. Justin Richer: It might also. Justin Richer: Be nonlinear in this case just like we were talking about that one service that might be calling out multiple things I could take any user that gave me a Federated login from two different idps and bound them to the same account and they presented a VC from somebody else and all of that is tied into their account maybe they did that because they needed to do a higher level of identity proofing and that's how they presented their proofing information. Justin Richer: All of that. Justin Richer: That's meaningful to me and it might be meaningful to the people that to the systems that that user might be connecting with Downstream from me and it's a lot of the same types of constructs and Concepts that again we don't really have a good way to talk about this this kind of provenance graph if you will of of entities and artifacts and identities moving through. Justin Richer: So to me that's that's one of the more interesting business drivers is all of this at kind of a macro level at a more sort of immediate level the different I mentioned about being able to handle Cinder constrain tokens in even inside of a single Cloud environment that's a huge problem that people are hitting today you know there are systems that the Gateway strips off the set of constraints and passes along. Justin Richer: The bearer token there systems that wrap the toe. Justin Richer: Inside it has its own internal job that needs to get figured out Downstream you know all of these different patterns that people are implementing often without really fully understanding what the trade-offs are and what the. Justin Richer: What the sort of the Hidden considerations might be and that's to me where the standards Community can really help because we can get together experts from all of these different fields that have similar problems and similar Solutions and figure out what the commonalities are what are the real patterns that people should be applying here if I make this decision to for example switch to Bearer tokens internally what is that what does that mean what should. Justin Richer: Should I be thinking about. Justin Richer: What extra things should I be protecting against in the in the case that I am making that decision. Harrison_Tang: Got it thank you. Justin Richer: To to help with that I'll actually pulled all dropping into the chat there is a. Justin Richer: https://www.ietf.org/archive/id/draft-gilman-wimse-use-cases-00.html Justin Richer: Use cases document that a few of us have put together and is an ietf internet drafts so this is this is not an ietf draft this is not a standard this is this for those unfamiliar with the ietf process and internet draft like this carries about as much weight as somebody's blog post just to be clear about the nature of this. Justin Richer: It said. Justin Richer: Put a bunch of work into this to document sort of the core a or a core set of considerations that that we would like to be able to look at inside the inside The Whimsy work as it goes forward. Justin Richer: There are others as well. Harrison_Tang: Got it and and since we got a little bit more time I'm just curious what are the trade-offs of the different solutions that you mentioned like for example stripping Out The Binding elements of Center tokens and you know or Raptor rapid into another another token that kind of things what are the trade-offs and then personally what do you think is because you mentioned the in this stack you talk about. Harrison_Tang: about the problem statement so what do you. Harrison_Tang: It is the kind of that direction for the solution. Justin Richer: I'll answer the second question first and that the direction of the solution and honestly depends mostly on what are the details of the specific problem that that you're trying to address there are a lot of related problems here and how you go about working with those is going to be different depending on what it is you're actually trying to get done for example. Justin Richer: Some systems. Justin Richer: Need extremely high performance when you're going out and working in a all of these different nodes so the the overhead of calling out to do a local token exchange even to a local authorization server can be deemed to be too much it's you know you're taking a performance hit every time you do something like that so. Justin Richer: Lucien there that you can apply locally one of the trade-offs of for example stripping out the center constrain portion is that you now no longer have any binding between who's presenting the access token to you and the token you're being presented you have to fully trust that the service that's presenting stuff to you is supposed to be presenting that particular token. Justin Richer: And there's nothing in the system that can actually tell you that directly associated with the token at the very least on like if you had a center constraint token you would have a good amount of assurance that not only is it the is is the token valid I can validate that not only is the sender valid but they are actually tied to each other in a way that's meaningful to me so this brings up an interesting point though. Justin Richer: In the oauth. Justin Richer: Ruby years ago there was an RC published for how to do Mutual TLS binding for oauth Access tokens and this is some great work it's gets used all over the place one of the interesting things about that work though is that the. Justin Richer: The oauth community largely looked at it as we are adding TLS protections to oauth token so we have these oauth Bearer tokens and we are adding this TLS presentation binding to the oauth Token so that we can actually be sure that the piece of software that was supposed to see this token is the software that is sending this token. Justin Richer: So that seems pretty reasonable especially when you're coming at it from from the oauth perspective. Justin Richer: Thing about that though is that the reality was actually the opposite if you look at the way deployments of authentic LS are and especially when things first started. Justin Richer: What happened was that it was people that were already doing Mutual TLS like for example many many systems in the spiffy Community they're already doing Mutual TLS and the access token got added to that so in other words I now no longer just have to say oh I know the identity of the service that's calling me and they're allowed to just do whatever. Justin Richer: Whatever on my. Justin Richer: Who they are and I trust them to just always be correct. Justin Richer: Can now add constraints based on the token that they hand me because they can give me a token that it's like yes this token says you're allowed to transfer money out of a specific account that's great oh hey and this token was given to you so I already know that you're allowed to make this money transfer call you're allowed to do that kind of thing on my my API but this token. Justin Richer: And tells me exactly. Justin Richer: What I'm supposed to allow you to do it can tell me an amount it can tell me a destination it can tell me a source can tell me all of that other stuff that are now no longer need to you know like these security properties that I now no longer need to encode in my API. Justin Richer: Like it's similar to in open ID connect when you call the user info and point you don't give it a user identifier you just say give me the user info for whoever whoever is there whatever the current user is and so because of that makes it really simple to program and really simple to understand you know you're not putting things into the API that that you don't have to expose. Justin Richer: And it's a. Justin Richer: And that we see with the with the sender constraining so when we start to strip that off inside these environments because we're now no longer talking directly to the client application to him the token was was issued we need to start making that that kind of trade-off and there are other systems out there that allow you to for example have a re delegated token either through token. Justin Richer: Exchange or through some. Justin Richer: Magical down scoping Like Biscuits allow you to do and that can be helpful but you also still need to be able to tie that to the identity to the identities of the presenters in order for it to be truly meaningful. Harrison_Tang: Thank you and Helen you're either unique you. Alan Karp: Yeah so you've been talking about Bearer tokens that are signed certificates as the capabilities address some of these issues. Justin Richer: Nope no it's because I actually haven't just been talking about Bearer tokens so. Justin Richer: The issuing a certificate that that allows you to do a specific thing and only that specific thing if we're talking about sort of you know rapid issuance of a certificate for a forgiving call and it gave purpose and tying that to the mpls layer you could do that but then that's effectively a you know. Justin Richer: Moving a lot of your Center constrains security properties into the processing of the transport layer and it's still only lets you go hop by hop because when I'm down on that leaf node and I have a whole chain of things I want to make sure that that chain was actually followed before it gets to me and you know certificates alone don't don't give you that. Alan Karp: Yeah I didn't think they addressed everything I just some of the issues like that for example you may want to be able to be authorized party mainly give want to delegate Mutual TLS won't allow that so but a Scientific Atlanta. Justin Richer: So here's the thing one of the one of the conversations that's been happening on the Wind Z list just in the last week is a lot of people saying things like Alan just did like oh I know about something that solves part of this problem and that's fantastic there are lots of things that solve parts of these problems I could go out and feel the system out of mostly existing components that. Justin Richer: It will work. Justin Richer: And it'd be all right you know I'm you know fairly confident and competent in in how to build out a securely architected system this point in my career but here's the thing there's not there's not really a. Justin Richer: Sort of well understood set of patterns and recipes and stuff that we can use that start addressing these larger problems that come when you start putting things together so yeah absolutely there are bits and pieces of the solution out there to lots of parts of this problem and to me that speaks even more strongly to the need to get the right communities together too. Justin Richer: To discuss the. Alan Karp: +1 Justin Richer: In the larger solutions that come when when you have these pieces. Alan Karp: And I agree with you I was just thinking of some of the pieces that you hadn't mentioned. Justin Richer: Yeah there's there's a lot of pieces that I didn't mention specifically so there's work the folks at City at signal not the instant messaging thing the other one the shared signaling signal sgml for the transcriber that that are looking at. Justin Richer: Transaction level token exchange so being when I can pay the cost of getting a new token on at the Gateway level where do I put the incoming token and that particular solution is looking at using Jose so it's a lot of sort of embedding and token composition and you know the data structure kind of like grows linearly as it goes through the system with everybody that needs to be able to touch it. Justin Richer: That's one possible solution to part of the problem and there's also stuff like you know if you're still in the Jose's face various Johnson selective disclosure jobs and things like that that allow you to sort of peel off different parts of the token as it goes through the system and expose it only to the parties. Justin Richer: That need it. Justin Richer: So there's there's some interesting work that's happening there spiffy itself is a really well used and well understood solution. Justin Richer: To its specific problem of I've got a piece of software it needs Keys how do I get that. Justin Richer: Like if you want to understand it the honestly I should have started with this. Justin Richer: Case that really made made it make sense to me is that how many systems have you started up and you need to go connect to a database and you've got to go Jam a database password into your code or configuration or environment somewhere how do you make sure that only the systems that have that are supposed to have access to that database get that password. Justin Richer: That's exactly the kind of. Justin Richer: Spiffy salts because when that software wakes up it doesn't know what it is it just knows that it needs to make this connection and have a value filled in somewhere the spiffy agent figures out you were the software with this hash your signed by you know this CI chain or whatever other bits that you want and so use this value when you go make that call and so we can now provision that type of stuff out. Justin Richer: Out in a way that. Justin Richer: That actually makes sense to the rest of the system. Harrison_Tang: Any last questions. Harrison_Tang: All right I don't see any more questions in the queue so thank you thank you adjusted for actually leave this discussion on machine identity I love it really enjoyed learning a lot and thanks for taking the time. Justin Richer: Thank you so much I want to encourage everybody here to please join The Whimsy mailing list that is wi MSE at ietf and read through the use cases document and please join the conversation we are at the stage right now where we're trying to show the ietf that there is enough interest in this community for this set of. Justin Richer: Of problems in this set of. Justin Richer: Potential solutions that we can that it actually worn setting up a new group in the ietf. Justin Richer: So please join the conversation. Harrison_Tang: Sounds great cool any last topics that people will bring up. Harrison_Tang: Right this concludes this week's wtcg meaning so thanks a lot.
Received on Wednesday, 13 September 2023 00:44:11 UTC