The W3C Credentials Community Group

Meeting Transcriptions and Audio Recordings (2014-today)

Go Back

W3C CCG Weekly Teleconference

Transcript for 2023-10-24

Our Robot Overlords are scribing.
Kimberly Linson: General sort of housekeeping agenda and then we'll let Justin get started and have a good conversation with him about Gene app Grant negotiation and authorization protocol so and Justin I would really appreciate it if when I turn the mic over to you you would give us kind of a before getting into the detail kind of a 10-1 of what that is and how it's used and so just to quickly welcome everyone.
Kimberly Linson: N and let everyone know.
Kimberly Linson: Are always following the code of ethics and professional conduct which I think the best way of sort of summarizing that is to always assume good intentions of the folks on this call we are all working together to solve the same problems and if we just assume good intentions of everyone will probably be in good shape to make the quick IP note we welcome anyone and I'm so glad to see so many folks here on the call today.
Kimberly Linson: Day and we're.
Kimberly Linson: Happy that you're here to participate if you are wanting to be a substantive a substantive contributor to any of our work and then we do ask that you be a member with the IPR agreement signed links to those agreements can be found in the agenda for today and we do hope that you will participate in the work that.
Kimberly Linson: Oh I'm not I'm not used to that Harrison do you think I can just try it again.
Harrison_Tang: Yeah try again.
Kimberly Linson: I'll see what happens.
Our Robot Overlords are scribing.
Kimberly Linson: Okay let's see if let's see if that worked.
Kimberly Linson: Yes okay seems that the transcriber is onto which is perfect timing for my next bullet point which is about call notes we do keep meeting minutes and audio recordings of these calls for posterity and so that you can go back and listen if you're not able to attend so many great topics so many things that are rapidly evolving and developing this community that we really want to have that historical archive so we do that and.
Kimberly Linson: If you are interested in contributing to the conversation.
Kimberly Linson: Of every one of you will invite you to put yourself on the Queue with the with Q Plus that will allow you to that will allow me to be able to manage that queue and call on you to be able to participate if you want to remove yourself from the queue you just put Q - and now is the time of our call where we have the opportunity to have introductions and reintroductions so I would invite anyone who is new to the community to.
Kimberly Linson: You tell us a little bit put yourself on the.
Kimberly Linson: And tell us a little bit about yourself and your work and your interest in this community and if you haven't been here for a while and you want to do a reintroduction and let us know what you've been up to we definitely would love to hear that as well so do I have anyone for introductions and reintroductions.
Kimberly Linson: All right well we have a healthy group today so if you are not comfortable introducing yourself and you want to just type that in the Q and let folks know you're here you're certainly welcome to do that as well and then the next section of our agenda is announcements and reminders so do I have anyone want to put themselves on the Queue with something they want to share with the group today.
Harrison_Tang: I'll just kind of preview the upcoming agenda so the next meeting we'll have Andrew to talk about mobile driver license now what's new the latest changes in MTL and the media after that we'll have Manu to talk about through age as a lot of you guys know California just launched their wallet pilot program that's built by Spruce and then in addition.
Harrison_Tang: to that it also.
Harrison_Tang: A selected the school's your kind of verification mechanism so Manu will talk about that and then the media after that we'll be having a Daniel to talk about the latest in open Wallet foundation and after that we'll have Sophia to actually talk about the D ID Technologies in healthcare so that's upcoming meetings that we have for the next four meetings.
Kimberly Linson: It sounds like really interesting topics again I think after iiw I know I'm feeling like there are so many interesting things happening and just this momentum in this community is very exciting any other announcements and reminders.
Kimberly Linson: Anyone have anything that they want to share around work items.
Kimberly Linson: All right well Justin we have a very large but quiet group this morning so hopefully you will you'll wake them up and get them buzzing when we come to the time for Community discussion but without further Ado I will go ahead and turn it over to you and let you educate us about.
Kimberly Linson: Did I say that right I guess that's the first thing I need to know or is it going out.
Justin Richer: Thank you so so yeah that's actually a question I get asked a lot is how are you supposed to pronounce this I personally say GNAP with a hard G but there is no official pronunciation there was actually a big debate in the working group about whether or not there should be but you know having worked on a number of other Technologies myself in including including this token format that.
Justin Richer: That is.
Justin Richer: W.t. and is ostensibly pronounced jaw and it says so right in the spec that that's how you're supposed to pronounce it but I've heard J W + JW TS and lots of variations on that in the wild so I've long since given up trying to have really any hold on an official pronunciation so G-nap is fine I don't care I've heard guh-nap and nap with a just a soft G like you know like.
Justin Richer: Like new and.
Justin Richer: Ultimately I don't think it it matters all that much.
Justin Richer: So hello everybody thanks for inviting me out to this and I am going to talk today about math which is a protocol that is currently in development at the ITF we're going to see if screen sharing actually works here just give us one second all right so I.
Kimberly Linson: It will work melt if you are not sorry.
Justin Richer: What was that sorry.
Kimberly Linson: It will work best if you are not on Safari as your browser any other browser but Safari.
Justin Richer: That is incorrect Firefox is also not so great with the Jitsi tools so I had to switch to Chrome today for this even though I don't really care for it.
Kimberly Linson: Okay well you knew it better than I did.
Justin Richer: But thank you for the heads up so it looks like I'm sharing on my screen I'm going to load up a presentation that I have just because it has a few main talking points I will say when I have this up I cannot see the queue so I ask that the there's please feel free to interrupt me if there's something on the cue that the people want to bring forward and so this is a set of slides about.
Justin Richer: That that I've had in my pocket.
Justin Richer: Is nothing that I prepared specifically for today which just means that we're going to be bouncing around through this presentation a bit and hitting the topics that this group clients most interesting so first off we talked about the name a little bit and can app is also what Smurfs say when they are bitten by the purple fly and they run around biting other Smurfs on the butt and it's actually part of the origins of the modern communicable zombie disease myth that.
Justin Richer: Debuted in electronics comic book.
Justin Richer: Years before Night of the Living Dead was actually done this is not the intentional origin of this but it turns out it's hard to agree on naming things and so we have get out for those of you familiar with oauth 2 this is not an extension or application of OAuth2 itself it's not intended to be wired compatible with oauth2 and that is a deliberate design decision will see the reasons for that in just a little bit this was meant to be an.
Justin Richer: Exercise of you know starting with what we've learned.
Justin Richer: To work and we go from there it's also important for me to say that this is not "OAuth 3" although it gets called back from time to time the oauth working group For Better or Worse controls The oauth Branding within the ietf community and the oauth working group has decided to at least at this time not to do anything called oauth 3 that said Can app is is.
Justin Richer: Really built on a lot of what.
Justin Richer: In a while to over the years which includes a whole ton of extensions and adaptations and lots of stuff that needs to work within side of oauth 2 is limitations and some of the stuff that we're seeing now like the self issued offering party in open ID connect or pushed authorization requests or things like that really don't don't really look like oauth anymore but there's some.
Justin Richer: Retched claims you can make about.
Justin Richer: I'm being compatible with the general model of OAuth what we decided to do with an app is really move beyond that because you know office not going anywhere but you definitely had a lot of limits that we've reached over the years so we wanted to ask the question if we were building all the stuff that we're doing in a while today and got a chance to address a bunch of the things that oauth really doesn't do very well what would that even look like so we decided to actually build.
Justin Richer: Something brand-new instead of building on top of OAuth.
Justin Richer: In to extend it we decided to take those Concepts and start with a new protocol with some key design pillars first off on like a while to which is really a suite of related protocols we really wanted this to be a single protocol with very clear extension points that's all about negotiating delegated access so you've got two pieces of software that are talking to each other.
Justin Richer: In order to.
Justin Richer: To allow one to get access to the other we wanted to be extensible in how we interact with humans we wanted to have a bunch of different ways of dealing with the different kinds of client software that's out there very importantly a while to was built at least initially around this Assumption of Bearer Secrets everywhere both Bearer tokens and clients secrets and a lot of the oauth world is now struggling to move past that so we wanted to start GNAP.
Justin Richer: In the space where we're already looking.
Justin Richer: At keys and we wanted to have a better a better model of how to request stuff and and kind of what that looks like so to deter right now that its core is all about negotiating access so off you may have heard called a delegation protocol or you may have heard of called an authorization protocol where in fact it is a delegation.
Justin Richer: Protocol what you're doing.
Justin Richer: Delegating a right of access that somebody probably a person has to a piece of software and grab at its core is really about that but we wanted to have this work in a way that is really it's about a conversation where you have a grant that moves through a bunch of different states as things actually actually continue so a request can come into a GNAP authorization server.
Justin Richer: And then.
Justin Richer: To decide well do I need to interact with the user or not and then while I'm waiting for the user to interact I can end up in this pending approval State and eventually I can get you the access token which I can then later revoke this is a model that is not really new you know this exists in the oauth world but it's kind of hidden in the oauth community in the oauth protocols it's you'll see the same kind of pattern.
Justin Richer: I'm baked into software without people really realizing that it's there.
Justin Richer: And so with cannot we really set to put that entire negotiation front and center and the way that that works is that the client shows up and it has a request that has a bunch of different parts in it.
Justin Richer: Includes hey this these are all the apis that I want to access and the kinds of things that I want to do there and by the way if you need to interact with the user here's my list of ways to do that.
Justin Richer: And by the way here's also a bunch bunch of information about me the client software I can I can prove that I have access to a set of keys I can give you identifiers I can give you out of stations my platform whatever you need and then also interestingly.
Justin Richer: We wanted to bring user information and right to the front and center of kidnap because I was as I'm sure most of the group already knows one of the biggest applications of OAuth2 out in the world today at least the interoperable applications evolved to is open ID connect and open ID connect is an identity protocol that's built on top of oauth by allowing you to delegate authorization to know who the user is right now and.
Justin Richer: So with ganache we wanted to make that kind of thing a first class.
Justin Richer: Citizen by looking.
Justin Richer: Ways that people were using open ID connect and building those core functions into the protocol now to make it a fully featured identity protocol with schemas and provisioning and all of that other stuff you would still have to add more on to it but the goal was to have that Delta be much much much smaller between GNAP and a full identity protocol than what oauth was with open ID connect.
Justin Richer: So a GNAP.
Justin Richer: Json object that gets sent as an HTTP post this is an important part of the of the protocol to mention here in oauth 2 we've got a lot of different ways that we can interact with the user in fact one of the first things that I tell people when looking at oauth2 Jump Ahead here for a bit is you know which which Grant type are using which flow are you using.
Justin Richer: Saying this is a flow chart from.
Justin Richer: Go on to you in action that we spend considerable number of pages walking people through this decision tree to figure out which Grant type you need to use in a wall and one of the reasons that this is important is that you know off each of these is started in a completely different way the implicit flow starts with the redirect the device flow is.
Justin Richer: Is a post to a.
Justin Richer: The client credentials and assertion are opposed to the Token endpoint and.
Justin Richer: This means that every time that you start something in oauth you need to already know where you're going to go next and how that's going to work in order for you to even start the oauth conversation and kidnap we didn't want that we wanted it to be a negotiation we wanted it to be a transaction so every single request and can app starts with an HTTP post to the same end point.
Justin Richer: To the only defined.
Justin Richer: One point of the authorization server and in this request what we're doing and I'm not sure if my cursor is coming through but in the top section here we're saying I want an access token and this is the list of things that I want to access here's information about the client so right now just identifying it with a with an identifier string and these are the ways that I can interact with the user.
Justin Richer: And the request starts out like that and it can grow and change depending on what you want to do say you have a more complex API auth has Scopes we have Rich data structures more on that later say you are registering client for the first time well in oauth you have to have a client ID and can app a client ID is an optional optimization for the cases where it makes sense.
Justin Richer: Really the.
Justin Richer: I'm going to happen is that you present a public key and then you present proof of that public key and then the authorization server can figure out like oh hey have I seen this public key before do I have that associated with something that I can trust in some fashion and then you go from there which means that in going up there is no Dynamic registration and point because you can simply start the conversation in the as can figure out whether or not it's seen you before.
Justin Richer: That is a really really powerful pattern to be able to allow the.
Justin Richer: Components to have these conversations because every single time I start off a request I might not know where it's going next but all of the parties are given the information that they need in order to make that next step decision speaking of which the response that comes back is also a Json object that has a bunch of different potential fields.
Justin Richer: Now you can have of course access tokens that come back for calling apis if those are already ready to be granted if you need to interact with the user well then you can you can tell the client oh hey here's how you kickoff interaction with the user next there's no discovering authorization endpoint and see stuff here and then sent back and all this other stuff like that if you can do redirects and things like that which we'll see in a minute then you declare that and it moves on from there.
Justin Richer: Definitely an interesting one to this group if the client knows information about the user let me go back to that request if the client knows information about the user the client can present that to the authorization server and if the authorization server has information about the user that can come back directly.
Justin Richer: To say if the client has say a verifiable presentation that a wants to submit to the as4 the as2 process then you can do that and that might be enough for the AS to be able to process the request without needing to get the user involved in a browser at all this is a really really powerful pattern that can happen Abel's that is very much more difficult to pull off in a wall.
Justin Richer: How to look a little bit at what the responses look like.
Justin Richer: This is one oh yeah there was one last section I forgot to talk about but this is a response that says I need you to get the user involved and then come check again so in order to do that we've got this interact section that in this case is saying you said you could redirect the user to an arbitrary URL I'm going to send you there and this is a non some going to we're going to use to get you back here when all of that is done.
Justin Richer: In order to.
Justin Richer: New this grant request here's all the information you need to do it I'm going to give you an access token that is only good for calling this URL and this URL in this access token value can completely at the control of the authorization server.
Justin Richer: Importantly they are bound to this request is bound to the same key that's the case you'd made that first request so these are not Bearer tokens that you're seeing they are all bound to the clients presentation token so after we interact and we go through whatever steps we need to and we get the authorizations that we need to we can send back access tokens which is this first bit up here so just like the.
Justin Richer: Access token.
Justin Richer: Or the continuation request it's the same data structure we've got a token value and in this case a list of things that are that are granted for the client to be able to see we've also here returned a an opaque identifier for the end user which we call subject information.
Justin Richer: And this.
Justin Richer: Is another Speck from the ietf called subject identifier formats and that allows the AS to say to the client oh hey yeah you're talking to me over TLS you know that it's coming from me I'm just going to tell you the user ID and you can trust that within this context if we need assertions we can we can talk about that also but we found that in a lot of cases open ID connect.
Justin Richer: Clients really.
Justin Richer: The jar and parsing it to get the identifier out of it and as long as the fields lineup they're pretty happy with that because they're talking over TLS over the back Channel and that's honestly not that unreasonable so what all of this means is that can app really is a protocol the instance of client software makes its request if it needs interaction it goes and gets the user involved to then interacts with the authorization.
Justin Richer: A server once that finishes we continue, and
Justin Richer: We Grant access.
Justin Richer: This is.
Justin Richer: What we.
Justin Richer: Of the grant transaction API so we always post to the as2 start like I said and importantly there's only a single a s URL that the client needs to know at the start so the client just makes its request it's going to use its keys and whatever proof methods are tied to that and if the client has a set of.
Justin Richer: If the client has a set of.
Justin Richer: Means of interacting with the end-user we can start negotiating what the next steps will be from there.
Justin Richer: And this continuation response.
Justin Richer: How's us to say hey you're going to call this API and then you're going to use this access token.
Justin Richer: Now an interesting thing about this is that one of the things we looked at in can I have when designing an app was what are the things that have been kind of.
Justin Richer: No baked into oauth2 that were really really kind of over fit to purpose one of the things that we found was refresh tokens refresh tokens are both under specified in that they're always Bearer tokens but they're always tied to the client credentials if the credentials exists and it's all kind of ambiguous how you do that with extensions like dPOP and the like or mTLS.
Justin Richer: But at the same time.
Justin Richer: They're very specifically for when the access token isn't good anymore use this to go get a new access token except sometimes you can still use it when the access token is still good and sometimes that means you get a new token sometimes that means sometimes you get the same token and sometimes that token gets replaced on you so there's a lot of sometimes has that happen with this so with going to happen what we realize is that this whole negotiation process this multi-stage process was really just.
Justin Richer: Cycle over time.
Justin Richer: Lion is saying it's making one call to say start this off and then it's being handed a resource that it can then manage over time and that management can be oh I got a call back from the front channel that interaction is completed you know here's the nonce calculations that you need in order to validate that and let's go and sometimes that can be a hey the tokens that I was using for this previous Grant requests don't work anymore give me some new ones and.
Justin Richer: That can all happen through the same defined API.
Justin Richer: Because it will.
Justin Richer: Because then that allows the client and the as to negotiate with each other about what's needed for each of those steps to happen.
Justin Richer: So the principle here is really all about Simplicity for client software.
Justin Richer: Want to use the same kind of access token to protect to protect the GNAP API that we would at the RS.
Justin Richer: And we also want to use the same key binding methods so that means that if the client is capable of calling the AS with the key binding method for that initial request then the clients already proved that it's capable of making that request and we can rely on that ability when we allow the client to call the continuation API so we just bind the access token to that same presentation method and we're good to go.
Justin Richer: So the next major pillar is all about interaction like I mentioned before I laughs who is one of the first things about oauth 2 is figuring out which Grant type you're going to do but it can app like we talked about we always start with an HTTP post and then the AS gets to process and respond to that.
Justin Richer: That turns out is that with a GNAP Grant request one of the things that it can do is say like hey this is the list of things that I can do.
Justin Richer: In order to interact with whatever users using if you've got an arbitrary URL I can get them to it somehow maybe I'll redirect them maybe I'll put a QR code on the screen and hey if there's some user code that they can type in that somewhere else then I can do that I can display that and I know a certain number of extensions and whatnot oh and by the way when you're done with interacting with the user here's how to let me know.
Justin Richer: And whether that's a redirect or a push or some other mechanism that comes through in an extension.
Justin Richer: Tas does is it looks through all of that and it says alright for the thing that you're requesting this is what's appropriate maybe because I don't trust Multi-Device flows I'm not going to allow you to do user code type in I'm going to expect you to go to a specific URL or use this extension that we've agreed on we actually work so the open payments group in Europe has the secure payments processor as forget the.
Justin Richer: Acronym but it's basically a web authentic stanchion.
Justin Richer: That they have a they have a GNAP wrapper for so that the client can say hey I can do this secure payments thing and the AS can come back with oh great prompt the user with with these parameters for secure payments and send it to the center point and then that's how interaction happens so we're no longer bound to this model of we assume that the user is always in a browser but when the user is in a browser we can we can use that.
Justin Richer: So the client instance says what it can do but the as gets to choose from that set.
Justin Richer: And importantly if the S decides that hey I don't actually need to interact with the with the end-user that's over there then I can just return is also in turn says toads and subjecting phone inhales now why would an as do that well maybe the clients already approved and I know that just by the nature of the client that's asking and I've got a risk engine that tells me you Dad this is this looks like the exact same thing that's happened before no need to involve the user this time.
Justin Richer: Because it would just annoy them.
Justin Richer: Or maybe the client is presented and assertion from a trusted third party as part of that initial request so the AS can say yeah for the thing that you're asking for that assertion covers you and you're all set.
Justin Richer: And so basically the negotiation here allows the client in the AS to figure out how and when to get the user fault now this particular use case.
Justin Richer: Came to us from a large internet provider who has been actually using a combination of the office certian flow and the authorization code flow in order to solve their salt their use cases what they were doing was that they would start with the assertion flow and then detect an error on that so the client would start one flow and if that didn't work the client would start a whole new oauth flow with the.
Justin Richer: The redirected everything from the start.
Justin Richer: Hold it together because this notion of what happens next is part of the negotiation.
Justin Richer: Let's see here.
Justin Richer: There we go that was the next bit that I wanted to go to.
Justin Richer: So I'm going to pause real quick before I dive into the next section but are there any any questions before I do.
Harrison_Tang: Yeah so Justin is it fair to say like an app is basically a complete completely rethinking of oauth 2 and then also can you also if so can you also kind of summarize like what are the big changes that you made because like obviously you change from the bearer tokens to this public key cryptography and then you also talk about changing and simplifying the flows like.
Harrison_Tang: like it feels like there's a bunch of changes.
Harrison_Tang: Can you summarize the top changes you made compared to auth to.
Justin Richer: This entire presentation is summarizing the top changes.
Harrison_Tang: So the okay so it does feel like there are tons of changes then like what do you think are the most impactful.
Justin Richer: That's yes that's that's what I'm that's what I'm showing so the most impactful are going to be that list that I gave right at the very beginning you know negotiating access around intent registration and having that be a single protocol having the flexible structure for all of the interactions.
Justin Richer: The proliferation of oauth Grant types which are no longer needed working with different kinds of client software which was the bit I was about to get into and having keybinding and Robusta cottle's be first-class citizens.
Justin Richer: Yeah I think with that it probably makes sense for me to just continue.
Kimberly Linson: Dimitri has a question real quick before you do.
Dmitri Zagidulin: Thanks my question is.
Dmitri Zagidulin: Given the flexibility of the protocol.
Dmitri Zagidulin: Be interested in or are there already existing profile for say using an app to request verifiable credentials and presentations right so basically using nap as an alternative to VC-API/OID4VC/DIDCommv2
Justin Richer: Yeah absolutely a bit it was talked about in the in the VC group a while ago but it was dropped by that group I'm not actively working on it but it's it really is set up to allow for that kind of thing both allowing the as2 except here I've actually got a picture of that both allowing the AS to accept claims.
Justin Richer: He's from.
Justin Richer: New user but also possibly a third party that's authorizing it and then basically distilling that into access tokens for API use but also as we saw the ganache response allows you to tell you information about the person that's there as well so it's kind of its own issuance API at the same time so you could either get a token that allows you to meant whatever set of credentials using VC API that you that you.
Justin Richer: Need which is one use case.
Justin Richer: It could return the return the credentials directly back into the client instance which in this example that we're hand waving over would also be the wallet remember each each of these boxes up here is a role played in the system and not necessarily a discrete device.
Dmitri Zagidulin: Makes sense thanks.
Justin Richer: Yeah thank you it's a great question and I think that it actually it fits really well into into this kind of model.
Justin Richer: All right which really brings us next nicely into this notion of what is client software so remember in the offworld we started off with two web servers talking to each other that was the use case that was being solved except that that kind of brought with it this notion that every piece of software would have a client ID now some of them have a single instance her ID like you've got a website and there's.
Justin Richer: One copy.
Justin Richer: And it has a client ID but sometimes you have something like a mobile application where all of the instances share a client ID and some or it's an SP a and so you've got lots of completely disconnected instances that all have the same client ID now sometimes those clients last a really long time and they only have a single user this is the installed mobile app case some clients are ephemeral and only have a single user which is like the S&P a case.
Justin Richer: And some clients have an idea cross many users and this back to the web.
Justin Richer: And there are variations on all of these and yet and I want to we require every single OAuth transaction to have a client ID.
Justin Richer: The reason for that turns out to be a side effect of assumptions that were made in the design of oh ah.
Justin Richer: All to was designed around the authorization code Grant type and everything else was a an optimization of that.
Justin Richer: And in the.
Justin Richer: Authorization code Grant type you start with a redirect in the browser.
Justin Richer: Now the.
Justin Richer: With a redirect in the browser is that because you're over the front Channel you can't have the client also sending a client secret because then the secrets not a secret anymore.
Justin Richer: But you can at least identify the client and give the AS some chance of seeing that things are probably pointing to the correct client and then you validate the client on the back end and when the back-channel calls come back and use the client ID is tied together that's that's all well and good but it can I have we took a look at this pattern and we realize the client ID really wasn't actually solving that problem the way that it.
Justin Richer: It seemed so engine app all.
Justin Richer: Is are identified by their keys some keys you create the first time you talked to the ASM it's never see the before some of them are pre-registered some of them get issued to the client software by a trusted third party that might be some type of pki system or even a workload management system like spiffy those keys get put into the software and it just uses it but in the cases where you do have pre-registered keys that you can refer to you can send the keys by value but you.
Justin Richer: Could also send an identifier but the identifier.
Justin Richer: Basically is defined to point back to the clients key so even if a client has been issued and identifier if it sends its public Key by value the AS is required to treat it exactly the same as if the client had sent it's shorthand identifier which allows you to have very very very dumb client software that doesn't know anything about these pre-registered instances it just knows how to send keys and.
Justin Richer: That's fine it covers all of the base case.
Justin Richer: Where's all of the variations and everything else including a client identifier is an optimization that's allowable for places that need it this lets us actually keep bits of the oauth are bits of the underlying protocol from leaking unlike oauth and that is a principle that is allowed us to not have to Define things like public clients and dynamic client registration.
Justin Richer: And and a lot of other things.
Justin Richer: Space that's going to have just doesn't need anymore.
Justin Richer: Which brings us to the topic of binding Keys now I mentioned before oauth is all about bear Secrets where what you have what you send what you verify are all the same proof of possession obviously works a bit differently you have two parts of things you send something that proves that you mixed it and you verify using part of it I'm hand waving over Decades of cryptography and related topics here the important thing is that keep roofs income app are all.
Justin Richer: Based on.
Justin Richer: The client being able to sign the message somehow so the starting request the continuation requests by default all messages to the RS are also bound and get app is flexible in how those signatures are actually calculated and presented one of the most most interesting ones and oh wow these slides are update sorry we're up to draft I think 17 on this now is HTTP message signatures now HD message.
Justin Richer: Signatures is.
Justin Richer: Very imminently going to become an RFC it's in the RC editors Q right now so the spec itself is done it is complete it is finalized it just needs to be cleaned up and published which is the state that it's in right now so we profiled how to use HTTP message signatures inside of canal and we were able to do that by basically saying all right no not only use HP Sig but make sure you always sign these parts of the message and this is how it ties to the Keys and all of that.
Justin Richer: Other kind of stuff.
<dmitri_zagidulin> oof now to go through the titanic task of upgrading the Fediverse (Mastodon, etc) from draft 6 (which is what everyone's on) to draft 17/RFC
Justin Richer: Foods that are based on Jose there are methods that are based on MTLS here we go this is an example of assigned an app requests so we have a body down here that says this is the access token that I want this is my client information and the two shades of orange here show us how the HP signature gets applied at the HP message we actually signed the method the.
Justin Richer: At URI the content type the content Digest.
Justin Richer: It's the body here and we send that off to the server for validation by processing the signature the as can can be sure that the key that's listed down here in the client section is the key that is used to sign the message we use the exact same process when we are calling the resource server and here we have the authorization header which is where the token actually gets put.
Justin Richer: The principle underlying all of this is to use http.
<dmitri_zagidulin> awwwww yeahhh JSON-RPC-GNAP when
Justin Richer: When we were starting to nap we had an opportunity to say well we could create an abstracted authorization delegation protocol that could be deployed across any number of systems or things like that and we decided explicitly to not do that we decided very explicitly to say if we were going to do this we want to use all of the Power of HTTP and then if an app needs to be deployed to protocols on top of protocols other than a.
Justin Richer: HTTP well then we would translate that we would.
Justin Richer: Relation of ganache onto some other system because the underlying assumptions of what the platform gives you are going to be different we saw that with oauth and Ace and working positively and that case and we've seen the negative of this with large abstracted systems like you know WS star and if anybody remembers the soap and rest Wars of the of the early.
Justin Richer: That's you know you'll know kind of what.
Justin Richer: So that gets us down to API access into this data model.
Justin Richer: So in off one you either had access to the API or you didn't you know want to we invented this notion of Scopes Scopes are a great idea and that they sensibly allow you to limit the access of the access token it's no longer just oh hey this user approved this therefore it's anything that that user can do it's like oh this user prove this for read only or this user approve this for just this one particular right.
Justin Richer: Record but in oauth.
Justin Richer: A found that Scopes eventually fall short so in can app we just we build a rich set of multi-dimensional objects to allow people to describe what you want.
Justin Richer: It works is that you have an array of objects and each object has a type field which tells you the kind of API that you're calling.
Justin Richer: Type field is basically sets up a definition for what the rest of the object can be we've created some reusable pieces like actions and locations and data types and things like that for the common Dimensions that you find when you're talking to an API but you don't have to use those in your API and in fact.
Justin Richer: Going to see ya so for example this is an open payments charges request so they did use the location but then they have this limits object that is a bunch of financial information that is only make sense inside of their type object.
Justin Richer: Now if you've been following off recently you might be thinking like okay this sounds a lot like rawr or Rich authorization requests well there's a good reason for that rawr is the back Port of gaps access request to fit on top of a lawsuit and a lot of stuff in cannot that's kind of happening that way now when it's in a while to you have to deal with scope and resource an audience and a bunch of other parameters and make stuff make stuff makes sense in sort of a.
Justin Richer: Larger scape you need to do form and coding.
Justin Richer: Super awkward in the request can get really big which is problem with you're doing you know authorization code Grants because that starts out in the browser where all of this goes and that's the only place to put it and going to have all of those problems kind of go away because it's built on this from the beginning and one of the things that it actually gives you is the ability to make these aliases so let's say I have an API where I have a really common thing that people.
Justin Richer: I'll ask for all the time.
Justin Richer: I don't want them to necessarily have to send the same structure every time.
Justin Richer: If there's no variables in this then really I just wanted to say I want metadata access so I can Define this string metadata that means the same thing same thing with this update image I'm not going in on part I'm not parsing update and then image and then applying it to write image data blah blah blah it's like no I have a string that's defined it says if you see this it means this block.
Justin Richer: Means is that I now have a data structure that can accommodate both RAR type objects and scope type strings because this array can have objects and strings in it next to each other because Json doesn't care.
<dmitri_zagidulin> easily fixable :)\
Justin Richer: I do want to make a note to this particular crowd that when I say the type here you notice that this is not an at context there's no dollar schema or anything like that there's no assumption that this is going to be an automated machine readable type of structure for systems to to process and get a does take a strong stance on that not being an assumption now if you want that to be an optimization within your systems.
Justin Richer: Sure that's fine.
Justin Richer: Doesn't say how to do that can I have two says that the AS needs to understand what that type means and how to map it to an access token because sometimes when you request something from a client well the a.s. is actually going to add additional Fields like for example this case it's a wallet identifier for the for the person that created this this charges request the client doesn't necessarily even need to.
Justin Richer: No this identifier but when the.
Justin Richer: Impacts the token it can go and see that and the principle here is that we separate the knowledge out by different domains.
Justin Richer: Now I could get him a whole bunch of advanced features this point you can request a mobile access tokens in the same request and receive multiple access tokens eventually bound to different keys and presentations there's a lot of fun stuff that you can do with can app it's a really powerful really flexible protocol but at this point I've been talking for about 40 minutes so I am going to wrap it up say thank you and hopefully take any remaining.
Justin Richer: Any questions.
Kimberly Linson: Great thank you so much Justin this was really really interesting so I'm sold but you don't have to sell me because I'm not going to be the one actually using it but what I am curious about is a my interacting with it how is it option of GNAP like am I without knowing it interacting with it on a regular basis or not yet.
Justin Richer: If you're doing your banking in Canada you might be but for the most part the adoption that we've seen is has been in kind of smaller silos and places that have kind of reached the edge of what OAuth really allows them to do but they had more of a you know a green field ability to decide.
Justin Richer: And how to address.
Justin Richer: Set if you're out on the wider internet chances are you're going to be working with a bunch of oauth base systems and so you need to be able to bridge between those anyway so there are a bunch of implementations out there some of them public a bunch of them proprietary but it's not it's not ubiquitous by any stretch least not yet.
Kimberly Linson: Okay Dimitri I think you are on the queue.
Dmitri Zagidulin: I have so quick question apologize first covered before in an example of the that previous access token slide is there is there a provision for typing the access tokens.
Justin Richer: Okay so that's actually a question so here access hope there's typing for the access tokens as far as the relationship between the resource server and.
Justin Richer: I was concerned because those are the parties that actually need to know about different token formats and things like that the client does not look into the content of the access token it is an opaque data object as far as the client software is concerned just like it is in OAuth.
Dmitri Zagidulin: I see end.
Dmitri Zagidulin: Okay got it thank you.
Justin Richer: Yeah but when the resource server gets gets an access token it needs to know how to understand it.
Dmitri Zagidulin: Got it up a part of the reason I was asking is looking at the rich authorization request it's pretty much isomorphic to both linked data authorization capabilities and UCANs and so that's why I was wondering using using the type parameter I could see how you could transport all three of those.
Justin Richer: Yeah you absolutely could and the map is a protocol kind of doesn't care what the format of the token ultimately is the relationship between the a s and rs does care sometimes and so you could you could definitely carry you know multiple abilities and multiple formats in through the same system and apply them where it makes sense.
Justin Richer: Great question them thank you.
Kimberly Linson: Any other questions.
Harrison_Tang: I'm just curious because I can app has so many improvements and so many ideas I bundling I'm just curious is it worth while to for example like earlier we have Mike Jones talking about demonstrating pufa per session is it worth while to kind of have different components and different changes as opposed to bundling all these things into one big change just curious about your thoughts on that.
Justin Richer: Well a lot of the changes that we made with an app where were foundational and like I said a bunch of pieces are being back ported to OAuth like the intent registration patterned you can see in pushed authorization requests unfortunately because because it's oauth you end up with something that you know useless something else URL and could and you and put something that you have to put me with proud request so it's not quite the same as the.
Justin Richer: The you know Grant request thing.
Justin Richer: An app gives you also from open ID Foundation we've got the Grant Management API and they've had to invent a bunch of constructs in order to be able to have that work you know Grant identifiers and life cycles and all of this other stuff that oauth doesn't really have that's that's had to be added on and it needs to be understood by people doing that implementation so for.
Justin Richer: Or for that.
Justin Richer: You end up with.
Justin Richer: You end up with a whole separate API that gets added on for just a solve that use case with an app it's it's fundamental to how going to have works that you're managing Grant access and so it doesn't it doesn't need to be added on same with like I mentioned there's no there's no client registration protocol you know I served as the editor of dynamic.
Justin Richer: Client registration.
Justin Richer: A while to we don't need it in gonna so yes you can add things to off and people are doing that but sometimes adding things makes this system a lot more fragile and a lot more complex to manage than it does if you just look at it in terms of you know how would you solve all of these at once.
Harrison_Tang: Got it thank you.
Kimberly Linson: I will we are just about at time so thank you so much Justin for coming and spending your time with us this was really helpful and interesting and thanks everyone for your questions and for being such a good community and we will see you next week thanks.
Justin Richer: Thank you very much.
<cel> ��