Internet Engineering Task Force 102, 17 Jul 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF102-OAUTH-20180717-1550

Description

OAUTH meeting session at IETF102
2018/07/17 1550

https://datatracker.ietf.org/meeting/102/proceedings/

A

B

C

B

Better yeah um so welcome to a the first session of faith. um We have a session that is shared with the acne, so the first an hour and a half will be off yeah and and- and the last hour of this would be an acne. So we have 90 minutes here.

B

This is obviously I. Am the note well everything that you say or contribute here is still a under the note. Well so make sure you're familiar with this a we have a diverse product. That would thank you for that. M minutes, taker takers, a Mike and Justin thank you and blue sheets are circulating already didn't have to be too close. It's good yeah, a.

B

We have a one document that that was recently published a RFC eighty four one: four, that's the authorization server metadata a and congratulations to the author's I think Mike net and John said the correct okay.

B

Thank you guys.

B

Quick status update here M so.

B

Can you can you guys close that door? Sorry.

B

And so I think the whole floor was just training.

B

It was just so.

D

That so, before this session or in preparation of this session, we met with some of the draft officers to do the Shepherd write-up for the device flow and also for the best contract. This document.

E

D

D

Device fluorescent just sent me an email, the device flow moved into pallet, which is so I didn't got advanced, which is good and he needs to review NAB's document on the JW s request signing.

D

And actually, oh yeah, so there's an action item for us to go through the comments to make sure that we sort of summarized on how we address the difference. I use she comments so that that would obviously help occur to advance the document faster because he needs to also produce a write-up for the document going forward. It's not just a working group, the Shepherd doing the write up, but also the the responsibility to do the write up.

D

So I will talk to Nath and and the other authors to work on that to explain I think, which is something another unreasonable request to explain how the comments have been taken. Care of.

B

And and the Durst documents will probably discuss most of those, so I think incremental authorization will be discussed today, em again jot jot BCP and MPLS. We started that right up, Homewood will be discussed today. Security topics talkin it will be discussed on Thursday and talking binding and talking exchange will be discussed later today. Okay,.

B

So here is a our jet agenda for the day, so we will start with the incremental incremental or authorization, but William I think he's a is representing remotely and William. Can you join the line here.

F

Hey Ron, hey. We can't hear you great get my slides up. Yes,.

D

Yes, this lights.

F

ah Okay, great yes, sir. Thank you so I'm here today to talk about the earth to turbo incremental auth, which was recently adopted by the working group. So thank you for that next slide. Let me just recap: while we're doing this, so the problem statement is something like this asking for the kitchen sink of scopes. Upfront can also be a bad thing.

F

Users will frequently want the context of an authorization request, so, for example, if an app needs both the the calendar and the contact scope, then actually asking for those different scopes in a context that they're actually used in the app is something that makes sense can I go to the next line.

F

So this is. This is basically what we want to avoid and I think. This is particularly relevant in this sort of new era that we're entering where people are very, very aware of the data that they're sharing.

E

F

Kind of considerations like that around Hoth next slide, please so the definition of incremental off in the spec is the ability to request additional scopes in subsequent requests, adding to a single authorization grant representing all scopes so far, so you could of course implement this just by making separate, completely separate and discrete orth requests and then tracking them all individually.

F

But the theory is that that is something else challenging to do if an app needed say five different scopes and wanted to request each of those separately, it would then have to track five separate authorization call five separate refresh tokens, so the advantage of incremental auth is that they get grouped together into a single grant. That represents everything the user has granted so far, particularly relevant for public clients. There next slide, please so.

F

When it comes to confidential clients, in fact, all of the existing spec doesn't actually stop you returning more authorization than what was requested. So what do people kind of implement this as a way of delivering incremental auth for confidential clients?

F

So the value of the spec when it comes to those is the inclusion of some best practices, security considerations and one additional parameter, which is include granted scopes, which is a way that a confidential client can kind of indicate that they want all of the granted scopes so far to be included in that response, and not just the one that they currently asking for next slide.

F

Please and the real innovation of that of this standard is to document how public clients can do incremental auth, because that was previously not possible at all and we're doing that by ur and you take an endpoint called existing grant. So when let's go to the next slide and I'll walk 3d.

F

So when basically, the app does three requests. The first one is completely normal for native apps and then the second one. The first two steps are exactly the same as no laws, so they'll just request, whatever scope they wanted. But if you look at this second to last line at the bottom there, when they're exchanging the authorization code for that second grant, they include you know, field called existing grant the Refresh token from the first request, and that will result in the access token and refresh tokens being returned on the bottom line.

F

They're containing the union of all that scope. Next slide, please! This is just visualizing how that works, so you have grant a and grant B and then what should be returned? Is the combined grant the union of both next slide?

F

Please, okay, so updated since the last eight, if it was adopted as the working group, which I mentioned, which is great and I've, been working here here at Google, looking with some other people kind of testing this out and sort of seeing what else needs to be added to the draft, so it looks like one thing we may want to document is exactly how the scope response parameter works with this draft it's sort of already documented.

F

It might be worth some best practices around that we, of course want to provide an RFC 841 for metadata field. That's an RFC so and the big thing is Interop and also I, guess reviews. So thank you to Austin. I saw your review this morning.

F

I really appreciate that, but yeah I really wanted to send out a call to action here if anyone is interested in this spec and if you have a client or a server that that can potentially use this very interested to to get in touch with you and to work on some interrupts there, no I'm. So that's probably going to be one of my main focuses going forward between now and the next idea next slide.

F

Please, and so with that point in mind, I'm happy to announce that the apple of iOS library does have support for this standard. Now, particularly the public client. One I realize been at Norma show code, but I just wanted to show this, because it's actually just just to emphasize how simple ease. So this is like literally the sum total amount of code that a client would need to provide in order to increment an existing grant. They had with the calendar scope.

F

That is literally all they have to do, and this is kind of like why we're doing why I really wanted to push this, and that is if we make this really easy for people to do then I'm hoping more people will do it and I think it's the right thing for users, and so if more people do the right thing the users, then then we all win next slide. Please and I published a demo using this, this new API, so the API by the way it has actually emerged. Yet it's in a pull request.

F

But if you, if you are an iOS developer and you click, this link it'll have everything a demo showing how this works using those new API. So you can try that out and, as I said before, I'm really interested to gets in the airdrop happening, so I'd love for if anyone's implementing is server-side. You'd be great to point this demo at your server too and see if it works and see what problems we have, if any all right last slide.

F

So that was my update um very very interested to hear what people think of the if any Wells has had a chance to review.

G

Their card Amazon nice.

C

B

Any more elaborate I.

F

Guess we can go over to Austin's feedback from LA today, if that's the interest yeah, there are a couple points raised. I. Do you want me to summarize them sure you want me to share those I? Think uh yeah, okay,.

F

She'd be under yeah. There is third from the top.

F

Great, so it was two pieces of feedback here. One was the way we way we documented how the the unioning is is done on the authorisation ground to also notice that I had a should in the spec there, rather than a must and.

F

Spec as well.

F

So the reason the reason I originally had it should there is I'm trying to kind of balance balance two competing things here. The let me just read the section that says: if, if the verification succeeds, the new refresh token issued in the access token response of the token endpoint should include authorization for the Scopes in the previous grant. So it's basically saying when the when the user, when the client provides the existing ground parameter, any new tokens issue should contain the Scopes from that parameter.

F

The only reason I really made that it should not a must, is I kind of always feel like it's up to the authorization so, but what what they want to do, but it's it is probably a little bit confusing to say that so should there, because, if you're sort of not doing that in you know in a normal case, then you're not really implementing this spec at all. So my plan there is to actually change it to a must but kind of qualify that with some words to say you know.

F

Ultimately, it is in the discretion of the of the server what they what they want to grant, but if you're implying is spec, you know in the normal case, you must include that so I hope that makes sense.

F

I'll just pause in case there's a comment on that feedback and.

H

About back Amazon, what about situations where the authorization server wants to support selective consent and potentially include in that the ability to guess revoke previously granted scopes? How would that work if this is a must yeah.

F

Good question and I think I mean that's coming another trend that we're going to see actually so you're, very topical and and for the most part, I think that can already be implemented in the bounds of Hoth. So I definitely wouldn't want to have any texture that would tie anyone's hand around selected consent. So I guess what you're saying is.

F

Potentially the existing grants could be shown on that incremental auth screen, that's not something that at least Google's in orientation does today, but they could be, and the user could actually revoke something as they reviewing and maybe granting or maybe not granting the next one. So I totally agree to your comment. I'm it's gonna be hard to come up with some good words ran out uh-huh, but I think we can. We can probably work at such then that it accommodates then yeah.

H

I think your original kind of instinct is making that us should at least not a must is, is right, I, don't think. If we make this a must, then we are tying implementers hands with regards to things like that, right.

F

I guess the wrinkle is, if you, if you interpret a street, if you actually kind of never do it, then then you have any whether the spec I suppose, maybe that might be worth noting. But but yes, it's more like in a normal case, you would consider that existing grant and likely bundle that in but I guess either way. If we keep it as a should. Maybe I can just clarify that you actually never do that then you're, probably not going to spec at all, does that dick.

H

Is telling me he has a suggestion so I'll? Let him talk. Ok,.

G

Great now, maybe framing it more on that the response shooting must include all the authorization that the user is granted and so by putting the user into the equation, then you're tying in to what the user is granted as opposed to whatever the server decided as being previous grants right. So that way, if any came in and out, it makes it clear. I like.

F

That, actually it's always.

I

Comment from the jabber from Torsten lourdes that the alternative is to return the scope with the token response that the client can determine what happens. But apparently that's what he just said yeah. I actually.

F

That is a very good point from twisting. This is something this spec does not today that they should so I think the OAuth spec actually already documents this behaviour. So if you are returning an authorization, we're sort of different scope than what was requested, you're, actually a meant to populate that field, but these behaviors not mentioned is highly relevant incremental. Also I'll. Don't me take those a note to add something as well.

F

Regarding that parameter and and like Torsten says, that is actually a good way for the client to figure out you what the heck happened.

F

Alright, so the second point here is the respect goes into a little bit of detail kind of some best practices around how to handle denials in the case of incremental authorization. You know one of the things is kind of not throwing the baby out with the bathwater. If you use a where to choose no for a particular authorization scope, then- and you know you shouldn't like completely abandon all the grants that you have so far- the app should actually continue operating. I think this is very important from a user standpoint.

F

You don't want to kind of add to the user or like really anticipate that they're granting scopes. They don't want to that's the whole reason why we haven't word creative spec, but Austin raises the point about how should the server handle it so I'll definitely add a section in that. I totally agree with the assumption stated here, which is that also the authorization, so that would not normally discard any previously rendered scopes. If the user didn't explicitly indicate that.

G

Take heart again, this brings up sort of another question: I, don't know whether the working group has looked into this anytime in the past, but standardizing token discovery, endpoint err, a client could call a known endpoint and get back all the Scopes that were in the token. So then they could learn what do they have now and then they would know what do they need to ask? For you know a number of the providers have a proprietary API for that, but standardizing that could simplify work for developers well,.

D

I've seen people using token introspection from the client to actually see what, rather than the resource of use for that purpose, but you're right.

F

Yes, I, agree, I, know Google employees more or less implements for tokio introspection snake which, which I think was actually not designed for that use case, but it kind of always works for it.

H

Annabel Bachman Amazon a similar point to what I said earlier. Let's I think we want to avoid assuming that an authorization server isn't going to revoke previously issued consent. If that's what you know, they may want to allow the the user to do that through that UI, if you're a user seeing a bunch of stuff that you've, you know whether you know you've granted it or not. Whether you know this is new stuff that you're granting versus old stuff. If you hit cancel. What does that mean? You know? Maybe it means you cancel everything.

F

That's a good point well for one I. Think I'll make sure, like this pig doesn't tie anybody's hand would relate to that I. Think he's! You know everything is up to the authorization server I mean I, am interested to capture usability, best practices and then kind of give advice to people in mulaney's. So that is an interesting question. It's only we have a yes or a no, and this is actually like a yes/no and there might be some other actions in the users. So do you think that's worth documenting.

H

There was probably room for a best current practice around that, but I have no idea what I don't think we as a community know what the best current practices worth right, consent and revocation are. So that's a project itself. Indeed,.

F

So maybe maybe just some non normative text just sort of presenting this is something that that should be considered I guess by implement it's sad yeah.

H

At the very least, in like a consideration section, perhaps right on another thought is basic question is: do we actually have an access denied use case where the customer or the user is not revoking? Everything like if I'm, if I'm a a user and I reject the new scopes, but the authorization server still says the old scopes are valid. Does it make sense that, for that to be an access denied, or should that be a success, and just issuing you back the Scopes you had previously because technically you're still authorized just.

F

Not right or the new stuff, so so one of the problems is for public clients.

F

Is that at the time of the authorization, it can be a little bit hard to know what scope that particular public client actually has, because you can imagine a case where, where there are two installs of the same public client used by the same user, that potentially have actually different scope, which sounds weird, but is it's only possible and I've seen this with with some like cloud-based CLI tools, so the way the spec is designed is is actually they second, the kind of incremental request.

F

If you deny it, it really just means like you're, just denying that particular scope with no implication on the previous one.

H

Be they asses behavior, because.

F

They might be, you know, sort of revoking scopes in the back of their eyes. Yeah.

H

So I'm saying, if we're going to support that kind of a use case where there could be a revocation of everything, then maybe it makes sense for us to reserve access denied for the case where, where everything's getting revoked and in all other cases, you're authorized. But you need to check what you got authorized for.

H

F

So I think the only blocker right now to implementing that is that the server is not getting indication in the request exactly which grant this relates to, because you could have two simultaneous grants to the same client, I'd be kind of in power, and so there's actually in a way, if you're supporting that behavior there's no way to kind of correlate them right now we did have one idea about this, which is on the authorization request.

F

The client could provide like an access token or something to sort of hint to the authorization server which which grant this is but we're right. Now it's not documented doesn't.

H

The authorization server has to be able to know what is like: what's consented and what's not like a each so in order to present it to the user, so I.

F

Imagine well well actually, the way this is specified. You would only present the the new consents, so it knows what's being asked in that incremental authorization request. So it knows what to present in that context, to you to give an example. What I'm talking about like imagine, you have a cloud product with various different scopes and you have like two laptops and two command lines, both interacting with some cloud tool.

F

In that case it's the same user and it's the same all with a client ID, but you could potentially have like one laptop with West, so sure right.

H

Now, iOS and Android app on different devices, sure wrong and.

F

So right now the authorization server in the context of that incremental request doesn't know kind of which of those grants it is. We could document another parameter on the request. I agree.

H

I agree with your statement insofar as it applies to the protocol as written today. I, don't think, though, that we want to go down a road where public clients and confidential clients are necessarily given different user experiences, which is sounds like where that would lead.

F

Okay, so the simplest way I think to solve. This is if the client includes an access token on the second authorization request. Do you see a problem with that at all? If we were to do it.

H

Besides putting an access token in the query string, that's.

F

That's the problem, I mean how else can we indicate I? Guess we could hasha I mean how else to indicate to the authorization server kind of like this incremental request relates to an existing grant that has been made in the past I.

H

Can tentatively think of some ideas but I don't want to try and blurt them out here in 30 seconds. So, let's, let's.

F

Take that as an exercise to continue.

H

That discussion all.

F

Right, it sounds good I think this is an excellent topic. Yeah thank you for raising it.

J

Justin richer and while we wait for Annabelle's ideas, the thing that I'm hearing throughout this entire discussion is kind of coming back to the fact that a woof 2 does not have any type of sort of structural model for what a grant is, and so that might be something that we as a group may want to take like half a step back to think at about how this works, how we might be able to chain multiple things together, because, ultimately, if you had a way to identify a grant, you could build up this kind of stuff that there might be something going on there.

J

There are a lot of other systems that you know, there's Emma and Seba, and even the device flow have all these temporary tickets to kind of tie different parts of the process together here. So we have approached this from a lot of different directions, but fundamentally there is no object. That is the authorization grant that we agreed on that like this is what it is in these what the parts are, which is why all of these assumptions about like how is this stored? How is this referenced?

J

What is it apply to is going to be completely different in every single implementation, so so I very much sympathized with the not wanting to tell authorization servers what to do because they've been doing it a certain way for very many years and coming in and saying that no, our model is better than the model that you correctly interpreted from the vague specification is not gonna fly so anyway.

J

That's something consider what I actually got out to talk about, though, was that the introspection specification we intentionally wrote that to be slightly vague as to who's supposed to be using it. The primary use case is very definitely the resource server talking to the authorization server. That is that's the job that it was meant to solve. However, if you look at how the spec is written in kind of what it allows in different places and stuff like that, the client can use it without really going off-book.

J

The trick, of course, is to have your authorization server implemented in such a way that it can safely allow clients to introspect, which is not a which is not as simple as it seems on the surface, having implemented that in several different systems. There are a lot of gotchas about allowing clients to ask what a token is good for so I think it that's.

J

If you want to go that route, that's that's the place to start and some additional considerations for how to use it properly within that context is probably the right way to go about it. Do.

F

You think we should actually talk about that use case here or that are you saying that's just a separate thing: I.

J

Think that, if it's that, if we're going to recommend the application of introspection to help solve this, this whole notion of I'm gonna go look up what my tokens good for and so that I only ask for the Delta or I go look up what the token is for to figure out. If I got what I asked for or something like that, then we should document that here the sort of the AAS implementation and security considerations for token introspection, as used by clients for this I, think that that would be. That would be good here.

J

F

I mean one of the goals of this state is to document how that scope returned value would be used to indicate to the client like what scopes they had to avoid the necessity of that lookup right. They might forget or them you know something might happen this or yeah.

J

And and and fundamentally, we all seem to sometimes forget as a community how stupid? Oh, our clients are and how they're not going to do most of the clever tricks that we allow them to do with all of these specifications. They're just gonna blast tokens until it works. Yes, I just.

D

I was just wondering whether it's really a good idea to do token introspection from the client when you're only interested in this course, because it's essentially you get the token you sent the token back. There's one additional round-trip lots of data being passed around you. You may get actually realistically more back than just the scope. You actually get a lot of data, so, like seems extremely wasteful, like in terms of what the round-trip and the what goes over the wire wouldn't be more sensible to actually pass a parameter along. That comes back.

D

If the token saying this is the scope that I actually granted. You asked previously this in the request and here's what you get well.

J

You know I'm just I didn't say: introspecting from a client was a good idea. I just said it was allowed by the spec, that's true or not strictly disallowed to be pedantic, so yeah there are a lot of downsides and one of them is that the data model that you get back from introspection is intended for resource servers. It's got a lot of extra information that clients generally shouldn't know anything about.

J

Also going back to the point about clients being stupid, generally they're gonna use the token and see if it works, I mean most low off clients that I have seen in the wild. Ignore the scope field. They get a token. It's the 200, the access token field. Is there they're happy? They don't check expires in they don't check scope. You know they don't do anything else. If I get the access, token I'm call the API hey the API failed.

J

Guess: I need to go, bother the user again and maybe pop up a screen that says no user really do click this or I can't give you the widget. You wanted so yeah, so it for most clients.

J

It doesn't make sense to do that extra round-trip, because they're doing a round-trip to see if the token is any good by using it- and they already have to have appropriate recovery for that failing anyway, for the token being revoked or not being strong enough or having expired or any any number of other things that they already have right. The tendency is to reuse those code, those recovery code paths, as opposed to trying to do something more smart and proactive.

J

That said, there are a handful of people who, especially with kind of back-end system, clients that you know, can afford to be a little bit smarter about things or it's worth putting in a little bit extra smarts. Then they do tend to do these. These pre-emptive checks for expiration and stuff, like that, because the failure case is more expensive than the check in those it's a trade-off, but I actually the vast majority of cases. It doesn't make sense. Yeah.

F

And I think one of the quirks of old two is that when you're making that a paradise, there is no stand-in response, because we actually don't document that header at all so doing that. Pre change is useful because you can actually avoid the standards mm-hmm.

J

Oh well, I mean you get back something in the HTTP for hundreds. That might mean your token. Isn't good right.

F

But we don't have a documented response for that. So right, then you have to be one with that on a per provider basis. Yes, yeah, yeah, okay, I think we're out of time. Are we yeah? No, you.

B

Know you have a few.

F

More minutes, whew, okay, great well thanks, Aaron I, think that gives us a pretty good list of topics to look on the next before the next meeting and just a reminder, if you are interested looking for people to test adding you drop with, please get in touch thanks for him. Thank you. Okay,.

B

Dick you're next here.

C

No one to thank for that yeah see.

I

The manual yeah.

G

Hi I'm dick Hart I'm gonna talk about the reciprocal Olaf, which is now working group document.

G

How many people were in Singapore saw the presentation a few of you so for those of you that, were there, here's updater and what happened: change, name from mutual ooofff, because brian didn't like mutual and to reciprocal, which I think actually fits better added, a reciprocal parameter. That could happen in the first flow so that the.

G

Party B could indicate what scopes they would like in the push and, of course it's been adopted as a working group document. So the problem there is essentially, you want a symmetric relationship between the two different parties.

G

Each of them is calling each other potentially and potentially the user could be starting it either of those parties, and so we have this today with Alexa and Sonos and then there's a number of other ones which I forgotten, which ones of ships and which ones haven't so I can't really mention anybody else, but it's deployed now between us and all between Alexa and Sonos, and so the previous flow for anyone that had tried to install Sonos on Alexa was super complicated.

G

You need to log in like numerous times to go through to do it, because you you, you weren't at the right site, and so you have to get bounced over to one site to go and start something and all over the place. So I go through that a bit here and the flows, you know the user is over in the Lexx. App like so knows indicates the Sonos authorizes like satsang.

G

Always user gets redirected to Alexa with asanas authorization code, Alexa exchanges that code for an access token, which is your standard flow, and then Alexis will send you back over to Sona to start the second flow and then Sona always sends you back over, which then of course drives a login with Amazon, because we started in the app, but now we're in the web browser. So now the user has to log in Amazon, even though they were already logged into the Alexa app and then the authorized Sonos and Amazon.

G

Then the users redirected back to Sonos with the Lex authorization code so known as exchanges that code for it, and then users rejected back over to Alexa completion, which I think the first version was even this clean. It was even uglier than this, so the reciprocal overflow I made the font a little smaller. So it also don't have screen.

K

G

Bit of a cheat there, so one through five is all the same step. Six seven and eight are removed, and so what the user is now back over at the Alexa app at the end, a new step is the user authorizes? What Alexa is going to grant so nose and then Alexa, just back channel called so nose. Token end point with their authorization code and provides a context for Sonos, bypassing so knows their access token and then standard flow in step, 11, which is Sonos exchanges, the authorization code for an access token.

G

So there's a scope now and so when Sonos comes over, they can include a scope as a another part of the flow.

G

So what kind of scope they would like, and so the Torsen asks a good question: what if how does party a know whether they should go and send a scope over it's either pre-configured or obviously the in this example party be sent a signal as to which scopes they wanted and then the reciprocal authorization codes it's a new grant type.

G

Thank you, I. Think Brian. You gave me the suggestion that we should use you have this kind of grant type and then the party B access, token and prayer persons comments. All this is is really for the party B to understand the context and then, of course, the authorization code from party a so that's an example of what that looks like.

G

Something that we're starting to do now and I'm thinking of adding this into the spec is, and it sort of follows, aren't.

G

Fortunately it was nice of Dennis that and have his talk right before this talk is this essentially is additional incremental authorization and so in the Alexa world, the skill could ask for something, and so similarly you know where you want to torment all the skill may only have been given a little bit of permission at first, when the account linking happened and when the users in the application land, but later on, when the users you know asking the skill to do something and the skill doesn't have permission say to get the users location or get their email address.

G

Is you could have a voice interface where you know Alexa asked the user if it's okay for a particular skill to get a new permission, the user says yes, and so then we'd like to go and update that to the skill, and so using this same interface, we can go and push a new authorization code to the other party for them to acquire new, refresh and access tokens that now represent the updated scope, and so I just want to call out that we reinvention this really being a symmetrical relationship.

G

I haven't really come an example where it's asymmetrical, where really the user can start at either side and either party could update the other's authorization implementations as I mentioned, and I got some typos that people have pointed out in the spec, but sort of opening up for discussion. People have anyone else think this is be useful. Besides the other voice assistance, the question is.

G

G

Anybody have feedback, aren't sort of that updating authorization flow.

F

Yeah I yeah, you said he said excluding auto here with voice assistance, but it as we have one yes I think this is extremely relevant and I've seen it very similar. You know set of steps that you presented so I think it's good good. Today.

G

Okay, any other feedback honored anything you think we're. We didn't capture.

F

Nothing yet but I mean. Let me take an action over here. Okay,.

G

Any thoughts are an including sort of another section that we, you could use this same flow for updating, an authorization that sort of picks up on your incremental. That puts it in what would be in a voice assistant world, so.

F

We've got that example. Was that Alexa asking if the user was happy to grant more Sonos? Let's go is that yes,.

G

F

Okay, that's extremely interesting so that that's in a very trusted relationship, I guess, but it makes sense you don't usually have to pull out their phone and review a web request. I guess yeah.

G

Well, just like you guys, we have speaker recognition. Yes right.

F

Nothing, it I think it make sense to do that. Okay,.

G

C

H

About Backman Amazon, so the current draft has the reciprocal grant request coming back over the as part of the authorization response correct with the authorization code and the state know.

G

H

I believe that's what it says.

G

The that there's a risk there's an additional scope, require a scope request. Was that what you're saying I'm.

H

On the ground, no, not that not the grant I'm talking about the mechanism by which Sonos would tell Alexa and your example what what scopes it would like to get. Yes,.

G

That's in the authorization code from Sonos right in that and it's authorized it's the initial of a authorization response. Yes right.

H

That, okay, so is there? What are the trade-offs around having that as part of the authorization response versus as part of the access token response.

G

That's all I always have to wrap my mind around who's, calling who, in each of these things.

G

You look at the screen, wait and see. That's right. Sometimes it's best.

L

What are you really.

L

G

H

My slides I got confused as the crew was calling up. So if I understand the draft correctly in step, 4 step 4 is the user has granted consent. @Co knows and has come back to Alexa with an authorization code. Yes,.

K

H

In that step, Alexa could possibly have received a scope value from Sonos right. This says this is what's known as wants, so my question is that so that's kind of coming over, like the less secure channel right.

G

And so you're thinking that we could have that in five right.

H

G

Alexa call Sonos with the authorization codes so knows. In addition to providing an access token and a refresh token could provide the Scopes that it would like right.

H

That that would get that over the more secure Channel the flipside. The counterpoint to that, though, is that that necessitates that, for five and onward is kind of happening, a synchronously, and that may or may not be the case depending on the back end of limitation.

G

G

Okay, yes, yes,.

C

G

On the list, yeah I I like having a more secure, Channel and I think functionally it's in the same place and adding more stuff in the redirect. It's always problematic, since it's much more limited in its ability, mm-hmm and, of course it's open, especially.

H

To if we consider other people and on the list have been talking about recently scope data and having some additional content along with just rather than just a static scope value, so you could imagine that getting bigger and being a problem right, yeah.

B

Is that does that mean you don't need that elixir ization code in this case right no.

G

No, usually it's I don't have in the slide here in step. 4 we're also the Sonos is including which scopes who would like in the redirect it does back to Alexa. So if you go to I, don't know it's. Oh I got this.

G

Here, yeah, that is where I was putting the Sonos.

D

With signaling, which scopes it was missing,.

G

In the other sites- and here yes- it's not listed there correct, and so what Annabelle was suggested is that it would actually be in this. No, not that call in.

K

This home, you.

D

Call that happens.

G

In five to go and add the reciprocal parameter, coming back from sona's as part of its response saying: okay, I just gave you this and here's what I here's the scopes. I'd like you to send me.

G

D

I, wonder, would you actually that may be a good idea to include that parameter, because that stage you could actually then fall back to the other mode, rather than failing later on, when the other, when you have the authorizations over not knowing about the functionality of this extension, or did you consider that case? What happens if you, you know I key go through, then it doesn't support that. Would it completely fail or could it fall back to the longer flow? Instead, you know what I'm talking about no.

G

M

You, in order for.

G

This to work both parties have to support it right, yeah, but you don't know.

D

G

D

All three parties, the authorization server headaches so.

G

No I know well there's really Alexa in its resources and Sonos in their resources.

D

G

It's really the to authorization, server, yeah.

D

So you just assume that they know about each other's support for it, for this function idea and that's it you if.

G

They don't know about it, then they wouldn't be able to do it right, but it would fail at some point. Yeah yeah well say.

D

What would it would it just say so know what say say.

G

We thought that Sona supported it, hmm but they actually didn't deploy it right when we would make a call.

D

With that back call to push a code.

G

D

Right, we can fall back to the longer flow that you should previously, or would it just fail or denied us fail, because.

G

Cuz, the other flow was essentially a bunch of super complicated UX that both people needed to do right so that you're longer flow isn't standard.

K

G

The the initial flow is standard. The longer flow was like a wacky way of trying to accomplish it. Okay and.

H

To add to that, if you think about how this would fail, you know if Sonos doesn't support it, then they're, just not gonna, ever send any tokens back or any any reciprocal scope back to us and if we try to give them something anyway, their token end point is just going to reject it. If so, no supports it, but Alexa doesn't then Alexis just gonna ignore any reciprocal thing that gets sent back. Sonos is never going to get a call to their token and point to give them tokens at that point.

H

If you wanted to fall back, you would have to be Sonos triggering the fall back. But how would you even detect that right like at what point? Do you decide it hasn't been called and then do you Howard so knows inject something into the experience. It's not really I think the.

G

H

G

That the current flow was actually a standard flow which it isn't step six years.

K

I non-standard.

G

Right sub, six, usually you're all done by five in the current.

D

G

D

G

Mom called him.

I

Relaying another comment from Torsten from Jabbar. The flow description given on slide six would be a helpful addition to the draft, since even you seem to get confused about about who's, calling who right. Thank you for pointing out the obvious person and.

B

What's this the, why is it what's.

G

That, because it isn't really tan, it's a different so slightly different. It's a difference that that's the new step is ten B, but it has a equivalent of what ten was in the other eyes. Other one.

A

G

You Torsten: how is your day today.

K

G

Be back comments so I'll do a new draft with pictures yeah.

C

B

Good okay, thank.

I

B

A

B

N

O

Close enough, okay, I'm gonna Jam three different documents into one update here, a lot of it. It's it's just sort of some status updates and overview, but a couple of these mutual TLS and token binding, maybe have some relevance to the pop token stuff. That's going to be discussed on Thursday and so yeah welcome to not San Francisco.

O

I've never been.

P

To Montreal before.

O

Supposed to be.

I

O

Won't go to politics all right, so I'm gonna start with oauth2 token binding, which first sort of got introduced to the working group in Berlin and IETF 96. Hence my go to this photograph here in Berlin.

O

So I talked to a few people about this, so combining in general and there's the OAuth application of it and then there's the lower layer technologies that make to combining work and I want to give a brief overview of kind of how that stuff works, which will maybe help inform how the OAuth pieces work and enhance understanding of people really not document.

O

I noticed one of the authors of that stuff is in here so I'm sure he will make sure I'm right on point, but there are three core drafts that make up that set of documents right now coming out of the token binding working group. The last meeting this week on Friday. The very very last meeting is for that working group for anybody's interested.

O

It defines basically three things how the use of token binding is negotiated in the TLS handshake, the protocol of token binding, which is really just the message format and then the application of token binding to http.

O

What token Bonnie does is enables this long-lived binding of cookies or other security tokens like tokens to a client generated public/private key pair on on the browser or or underlying platform. The use of this is negotiated in TLS handshake via TLS extension.

O

A possession of the actual token binding key is proven by signing the TLS exported key material and then sending that, along with the public key and a few other things as a encoded, HTTP header, on every request and then in turn, the server can bind cookies or other tokens to that key, at least in the browser use case, the key is scoped to the effective top-level domain, plus one the the scoping around OAuth is a bit ambiguous and I intentionally, but generally that's the scope, at least in web browser cases and then in federated.

O

So, across the million cases where you want to bind to a key, that's used in a different domain, there's this thing called a referred to combining versus, what's normally called the preferred excuse me provided to combining or the provided is between the client and the sort of the main server. The referred enables the client to communicate a key that would use with a different server so that that original server combined tokens 2.4 its usage a little bit more graphical showing of how this works in the TLS handshake. There's just hello.

O

Extension number 24 if you're interested that the client includes in its client hello, along with basically what signature algorithms it supports to do, tow combining there's, there's three defined right now and then, if the server is happy with this and wants to do tow combining with this client, it responds including the extension and this its server hello, same extensions, same structure, but it only has one of these key parameter types was the key signature type, basically indicating the client hey. This is the one that we're going to use in this case.

O

In this example, the client offers up a couple, different choices and the server responds with okay. Let's do two combining and please use ECDSA with the p2p civ curve with me, assuming negotiation isn't successful in the TLS handshake, then on every subsequent HTTP request. The client includes this header, which is the sec token binding header, with an encoded token, by any message in that message, that can be more token bindings. Each individual took combining indicates the type which was either to provided or referred.

O

I talked about earlier, so see, they're saying this is the one I use with you normally or this is one that I use with another server the token binding ID, which is basically a name for the key, the public key with a type indicator as well, but it's effectively the public key and then a signature over that type.

O

The key type and the exported key material which is defined in RFC I, can remember the number, but you can think of it as basically a like a cryptographically, secure identifier contextualized for this usage for the individual TLS session, and then there's some room for extensions. What this does is when verified properly.

O

This proves that the client possesses the private key with respect to that TLS connection corresponding to the public key that was set in that message, and these keys are long-lived and span TLS connections, so, while TLS connection might be torn down, expired or whatever the token. The actual binding to this key can persist beyond that, because the the signature is is over the ekm for the TLS session, but the key itself is longer-lived.

O

So if a new sessions brought up, the client just needs to use the same key in sign the ekm from that session, not session. Excuse me connection.

O

This idea of cross domain or federated token binding is also supported in the web browser use case. There's an HTTP response, header that the the relying party or client in the Roth of an ID world includes on its redirect over to the IDP or the authorization server, and what this does is it's just called included referred token.

O

Binding ID is true what it does is it signals to the client that or the browser that it should reveal on the subsequent requests, the IDP, the both the normal token binding.

O

It would use as well as the token binding that it would use between itself and the reliant party, and this allows for that identity provider to bind tokens that to the key that the browser uses with the rely on party basically binding for the when it comes back for the initial connection there um and that's the provided and referred as the the name and the distinction between the two again provided as the one with that's used normally with their server you're talking to and referred, is from a referred site in this case.

O

It's the same same header and just inside of that encoded message. It actually includes two token bindings. Instead of one and there's guidance in the document itself. That basically suggests that generic token binding implementations should be able to send referred, based on some other signal to the API itself or from the application, and, ultimately that's what a lot of oh F is going to rely on. Is the hopes that implementations do in fact expose that in a reasonably useable way?

O

So with that in mind- and it was quick, but it hopefully gives a little bit of overview. The oauth2 token binding standard, that's being worked on within this working group, basically provides an oauth2 proof of possession mechanism based on token binding that defeats replay or play of lost or stolen security. Tokens of all sorts, probably the most interesting and the most applicable use case is binding access tokens. You bind those against the referred to combining ID, similarly sort of supporting that the federated use case.

O

So the client makes request includes both the normal token binding idea that it would use with the a s as well as the token binding, ID or key that it would use with the resource server. The authorization server then binds the access tokens to that key. That would normally use with the resource server and thus provides this proof of possession mechanism around the access. Token binding it to the the key use with the resource server and this can be represented and in the jwq access token, as well as the introspection response with the CNF.

O

The confirmation claim to find anything in RFC, 7800 and inside of that a new confirmation value, tbh forto, combining hash member. So it's a sha-256 hash of the token binding ID included inside either the introspection response or the the JWT. That basically, is a hash of the tow combining ID, which is what allows the resource server to make that comparison and check whether in fact the the issued token is bound to the key, which is in turn proof possession of by the client there's.

O

Also some text in there about binding, refresh Durkins just to the provided token binding ID there's some support for binding authorization, codes to variant flows, around native app clients and web server. Clients are a little esoteric. I won't go into the details and then speaking of esoteric, there's also some language about binding JDBC, based authorization, grants and jibiji client authentication.

O

That's it in a nutshell: won't go name deeper details, but I will cover a few happenings since London draft 7 was published and really the only main difference here is. It was clarified that the encoding of that tbh value is basically for URL encoded, but that's a somewhat ambiguous. In some cases it was clarified that that does not include any of the trailing pad characters or white space or anything else.

O

This actually was a result of a review on the MTO stuff from Justin that was equally applicable here, so I, just added the clarification and I updated and affixed a few references that were either referencing wrong parts and other documents or sort of the the HTML tooling, where it does self references when it shouldn't erase to those as well as update, you know, related not directly, but somewhat related. The open, ID connect, token bound authentication draft. A new draft of that was published, and it's worth mentioning here, just because the tbh.

O

Confirmation claim is actually defined in there, so the same clarification was added in both places, even though it's sort of the the normative definition of it is in that draft.

O

The three underline sort of quarto combining specifications are I've said it now, I think two or three, or maybe four ifs in a row that they're almost done. But in this case they really are almost done. The token binding over HTTP is in the RFC editors cube, which is really good and then not far behind it.

O

The TLS extension for negotiation and the token binding protocol itself are, in this approved announcement to be sent so they're just waiting for a tea, follow up there and I think they're close ish, so it shouldn't be much longer and that's where we're at with toe combining 4'o ah next one. The sorry.

N

Call my DNA I'm thinking about to AP's reside on the same device, whether it they can share a TLS connection, and my understanding is no because the token binding negotiation is at the TLS level. So if one app already has a TLS connection to the same authorization server or a resource server, then another app should initiate another TLS connection so that it can't have a different configuration for the talk combining whether the application be wants to use the talk combining or not.

K

John bradley yubico and one of the chairs of the token binding work group, so the definitive answer is it depends so alexei who's. Eyeballing me would probably have the better answer for Windows, which probably has the most advanced implementation, but it's going to if, if you've implemented token binding by including CRO net into your application and every application has its own key store, then yes they're all going to be different. If you're running say on Windows that actually provides an API.

K

There may be a way to actually share the same TLS connection and token binding via some magic flags. That alexei is now going to illuminate us about.

Q

It's under a but yes so under a book called Microsoft, so each application will have its own till that cos connection and unassuming, but the you know the token binding keys can be shared and that's platform specific right. So, like the extent to which token binding keys can be used by multiple applications is platform. Specifics on Windows we have a concept of app containers and if the applications are in the same app container the same integrity layer level, then they can share tow combining keys.

N

Calm eyed again and the first motivation of the pixie is to distinguish two applications and deciding the same device to not confuse each other, so armed fair. How the context of the token binding ID we've got sharing materials, so they there should be an API between the application and the operating system, so that I am who and who, on my tour, combining keys fancy, especially on the first authorization case and later token binding token bound token to the resource. Er.

K

Right so again, that's application specific, so work, that's that's! Probably the part of the HTTP spec that it took us the most amount of time to negotiate with the iesg is trying to explain that you know different vendors are going to have different api's and slightly different takes on it. So on Windows, apparently that you have some concept of an application group, so they can only share if they're part of the same ie signed by the same developer, key or some such thing.

K

Perhaps Android will have a similar mechanism, but since they haven't and I said how they're going how they're going to expose it on Android I can't we can't answer those questions until the the various operating systems actually implement the the api's. But there should not talk in binding, IDs or hucked, and combining keys ought not to be shared between completely unrelated applications in a single browser.

K

Yes, it's a single pool, but again well, even in a single browser, it may not be the same pool because some people are creating separate token binding keys for private browsing mode, etc. So, again,.

A

K

So so it we'll have to see how that plays out as the as the developers actually implemented it for native apps.

N

Called my arm say: okay, I think I understand the whole say picture right now, but I'll say it could be convenient. Whether say description of this discussion in the job draft or in the document or somewhere like and say, implementation, not or something that would be greatly helpful.

H

Annabel Backman Amazon, so regarding token binding of access tokens received from the token endpoint, it wasn't clear to me: is there a limit? Is it only one referred token binding that you can include, or could you request an access token that is bound to n different referred token token bindings referred token IDs, whatever the right term is, the terms are a little hard.

O

H

Okay, so, which.

O

Is a limitation and intentional limitation both of the way that the tow combining message is structured and only at least at the HP layer only allows a single referred as well as the confirmation method claim that we have only has only allows for basically one confirmation type of each you, your question sort of maybe begs at the scoping of the keys, and that's why I mention earlier that Olaf is a little bit how to pass it off is a little bit loose in in a browser-based world, their scope to the effective top-level domain plus one so that they don't they're, not more broadly scope than cookies and privacy considerations, and all that an OAuth client given the right api's could could quite conceivably use the same token binding key across a wide variety of resource service.

O

H

They have a trivial deployment of their system.

O

It's it's the client that that's largely managing them, so they have a single key that that they use with right.

H

And if you're talking about a widely distributed system, where you know it's completely different services in your back-end that are using tokens for one scope versus another, you know trying to get all of those pieces to share the same a token, a binding ID, particularly when you consider that that token, binding ID is actually getting bound like up at the.

H

The the VIP or the load balancer somewhere away from the actual systems that are trying to do stuff with it that actually know they need to share. There's some I I. Don't really think it's feasible to just assume that that's going to be able to be shared, so I think we should think about how we can get from a refresh token to access tokens bound to indifferent token binding IDs.

O

It you know one of the reasons to binding it to a key is so that you have to have that key in order to use it and and I recognize that access, widespread access and distribute systems to private keys can be problematic. But what I don't think we're in a position where we want to undermine the value of the protocol to support that kind of case? Let.

H

Me, let me rephrase my my suggestion: it doesn't necessarily have to be a single access, token bound to multiple referred token binding IDs as long as there's there's a mechanism for a service or for for the client to get an access token. That is bound for a token binding ID from some other service, separate from the one at request now seriously it.

H

This probably just falls in the realm of best practices, or you know non-normative so text but I think.

O

Maybe it is some neurotoxic azide thing if I'm understanding correctly, that the draft would support that right now you can present a refresh token with the referred to combining ID for this service, use that and then at some some time later present the Racine refresh token, with a different referred to combining ID and get a new access token bound to a key suitable for using this service, but.

H

There are some implications of that. You know as far as those tokens have to continue to both be valid. You know this is the subsequent refresh for a new token shouldn't invalidate the previous one. There's implementation details that fall out of that, but again aren't normative, but are probably worth being discussed as best practices are not normative. Texts.

K

So we have identified that in some clustered environments, where the the coinage is being distributed across the cluster, it may just be the token binding. Isn't the right answer that well, mutual TLS may actually fit better for some of those server based applications. The sweet spot for token binding tends to be more than mobile applications, which are dynamic and generally not clustered, clients that.

O

Is true, although there's there's wording and important here specifically for allowing a client to have an unbound refresh token, so you can be used from different nodes or whatever, while still obtaining bound access tokens for for outbound use specific to a key that only they have.

H

Actually, a lot less worried about the refresh token being bound to a single token binding ID, just because that's having a central system, or at least a single distributive system, that is doing token refreshes that just kind of a reasonable thing. It's the access token that's potentially being used by n different client systems to you, know M different resource servers that where I see the problem but I, think I think it's a good point that if this doesn't have to your token binding, isn't necessarily the hammer to use on every now. That's absolutely true.

K

So, as far as the resource server is concerned, you're either you or some sort of introspection. So in principle the token binding ID for that particular access token can be contained inside of the access token, so you're not really just because you're creating a new access token, potentially for a different part of the client. That's that's talking to that resource, or both of them can be valid at the same time, you're not revoking it. So I think there may be some of these. These larger sort of edge cases that we might want to go through.

K

If we have some extra time here, but the again for the larger server implementations, it just may be easier to use mutual TLS, which still works.

B

So we've got let's you might have to take that so thick you have a common. Yes,.

G

The card Amazon yeah I, haven't looked at this back in a while, so I, don't know if this is included, but just picking up on what they're talking about one of the issues in the past is that your TLS layers manage at your load balancer, but your access token is out the application right, and so how do you get the trust where that the ID vis negotiated somewhere different than where the app's trying to verify it sounds like not necessarily that maybe some standardization around? How does a load balancer?

G

What what header does it pass that down to the app? Is that that's a fan? Okay, okay, tastic.

O

I did and so I'm working on exactly that. If I understand you correctly and it's gonna be discussed on Friday last thing on Friday, if you're still around, please come to the token binding working group session and express your support for for such a draft. Okay,.

G

O

Thank you, nice. It sits in the token binding working group. It's call, it has a horrible name. I can't do better. It's a HTTP tow combining with TLS terminating reverse proxies or something like that, but you it's really short, but you can find the draft. So yes, I, agree. It's a problem that I'm trying to try to put out something. That'll help solve it. So.

B

So right it, you want to give a quick update on those documents.

I

O

It's five minutes: five minutes no.

B

O

All right, ooofff, mutual TLS- some of this is give a real, quick over being contact. Why is this being worked on? It's.

O

An enhanced security profile of OAuth 2 based on TLS client certificates, mutual TLS. The draft is already being used by open banking PSD to ask sort of regulatory regimes, as well as being preference of profile by other stos. What is it? It's an asymmetric key based, client authentication method for for the client to the authorization server using mutual TLS.

O

There's two methods take PK I based in a self-signed certificate mode and then also mutual TLS certificate, bound access, tokens for proof of possession protected resource access, so actual pop tokens, and this similar to to tow combining but with a different name, uses a confirmation.

O

Member inside the confirmation claim this one's called x5t pound sha-256, and it's just the shock to be 656 thumbprint of the certificate embedded inside the the access token confirmation clam. A few things have happened since london working group last call happened, I was on vacation for some of it, so that was fun getting the feedback was trying to relax on the beach draft. Seven eight-nine have been published. Mostly, it's been editorial clarifications and improvements from people making my text better. Thank you.

O

All one sort of important thing, I think is worth noting here is that the I dropped the use of the sender constraint, terminology with respect to access tokens, because a reviewer pointed out that going back to the pop architecture. Document sender constrained is defined as they as a client, authenticating literally authenticating itself, via some other method and having an access, token constrained or bound to that client. Whereas this this one actually is kind of a weird middle, but more than anything, the access token is, is bound to the certificate itself and not the client identity.

O

So trying to be more consistent with terminology here. I just got rid of the sender, constraint, terminology and I include a picture of NAT here, presenting at a conference just a couple weeks ago, extolling the virtues of sender, constraint, tokens, and this particular draft I- guess he's not here, but I was hoping to give him a hard time about using the wrong terminology and push on it.

O

But that's the only major like difference, that's not editorial and that in turn came along with a changing of a metadata parameter, name to reflect that small but legitimate, breaking change and that's all the stuff. That's really happened and I wanted to make the pulp fiction reference in here trying to find the shepard for this document. But this has.

K

All been taken care.

O

Of this morning we got a shepherd start. The shepherd right up, so document state has been changed, so this is now. This was legitimate on Monday, but is no longer accurate. So thanks for doing that, things happen quickly here in the IETF.

P

O

That's in these are moving thanks for all the reviews, I'm looking forward to it progressing Oh token exchange now in draft 14 real, quick overview. This is like a STS framework via the token endpoint, on an authorization, server, SD, SPN security. Token service I want to try to provide contacts here, but it's hard because it's really sort of a Swiss Army knife of just token in token out actually two tokens and in some cases and it's oaken out with with you know, claims or content representing that delegation.

O

This is just one use case which is sort of the resource. Server as a client gets an access token in from a normal off flow and in chain exchanges that, with its own authorization, server some other authorization server, sorry its own authorization server only to to get a token, that's appropriate for usage on some back-end system. The details are here: it's just, but it's one of many use cases that are facilitated by this one. That I just hear a lot.

O

That's enough for context and an opportunity to show a picture of my kid from a year ago happening since I eat 99. So 99 in Prague was actually the last time I presented on this because it's been sort of in the throes of review or latter, not not working group. But a lot of review. We've had graphs, 10, 11, 12, 13 and 14 publish clarified some stuff around the Act claim.

O

The act fame is the actor sort of a claim about to whom this token and its privileges have been delegated, and it says that it just clarifies that only that the top-level claims about the subject and the token itself, as well as the current actor, which is the most recent actor in the in Act claim, are actually to be considered when applying access control decisions had several clarifications and editorial improvements. Stuff mostly out of 80 review. I did change with working group, consent, scope and client ID claim names to what they are now.

O

They had previously been SCP and CID to align more consistently with. What's what's in the introspection draft and try to just normalize names, I try to really to go with the shorthand convention there, which made sense at the time, but in retrospect and having some developers and other spec writers. Look at it.

O

Consistency between the two made a lot more sense and will make even more sense, probably when Torsten presents his next draft here about signed introspection responses because then they'll line up some new, you are eyes were added a long time ago to represent sam'l tokens, no normative stuff around it. Just giving you our eyes to say hey. This is a sam'l token and I have answered quite a few questions and with this fact that there's no normative support in the document for validating or issuing access tokens from other authorization servers.

O

It's always been that way, but it seems to be something that some people are interested in asking about, but I think that the complications, as well as the security considerations, definitely warrant keeping out of scope for this document and having those kind of use cases be supported by a more explicit exchange such as the GWT bearer grant or jbt assertion grant.

O

Currently, this document is in ad evaluation waiting for write-up on a point raised that I think I've addressed with that Act claim I think ekor left. So it's sort of that kills a lot of this type slide, but I had three things: I wanted to do in this slide. One is I, always include pictures of the places where we've been are gone. Closest thing I had here was a picture of me in Bangkok from almost 20 years ago.

O

I did want you to get the one night in Bangkok song stuck in your head, so hopefully I'll have that going on the rest of the night and the main point of the slide was to try and sort of go into actually closing out his point needed and moving things forward, because I think it's been taking care of him. We're just sort of sitting here, but he's he left earlier. So yeah.

B

B

Okay, thank you.

B

Five minutes.

B

B

Kenny, yes,.

B

B

Is Houston.

B

Okay, it's maybe.

B

Okay, Torsten getting us.

E

Not there, you go.

M

Hey guys, can you yeah.

B

We can now you have five minutes this.

M

Is such a complicated time?

M

Okay, good yeah, then, is the presentation visible? Yes, okay, because I can't continue it um so I'm gonna, my name is Dawson notice that yes, I've, come and I would like to present a individual draft that I did with you know from connected ID, it's a small extension to token introspection next slide, please which allows a resource server to request and then authorization, so it responds with a chart. We thought, can you please? Oh I can't see which slide you're showing so assumption is in slide number two. So it shows the the extension.

M

So the client asked for a chart, representation of the introspect response and the a s just answers with representation which allows us to sign and provincially, also encrypt the response next by please. The use case, for that is quite simple. We are.

M

We are looking into my eye assurance level use cases which is payment and electronic signatures, and those use cases require the resource server to keep track of all the data that it consumed from authorization, server for auditing and number affiliation our purposes, and that's why it's a good idea to have a science assertion on resize and use of structured access. Token is not always possible, for example, iterations where you want to have an integrated authorization which allows the client to obtain a grant.

M

That is good for interacting with different API is, for example, to sign a contract on one hand and to initiate a payment on the other side. So we can't carry all data in one shot because it would violate privacy regulation and that's why we sing a token introspection is a much better fit, but our top introspection needs to support, signing and potentially encryption, and that's why we have written this graphical next slide. Please it shows in detail how this is going to work. It's quite simple, and there is a new except declined.

M

You that the resource or uses the accept our application, slash dot. Gwt next slide. Please das just answers with the perspective GWT next slide. Please um and the a s determines whether what with algorithms are being used and whether there is just assigned a judge or a a signed and encrypted job either by default or the a s may supply some configuration data of why our reservation, the draft also defines some registration ways for that, following the pattern established by the Open ID connect on dynamic client reservation next slide, please.

M

So that's the last slide. I already presented it off in London and got some feet some pushback on the topic, because we also had included proxy use case because of the fees by feedback. We got rid of that on focusing on the non-repudiation between our s and is entirely so. What we did is we incorporated. We did a version, oh one, and we incorporates feedback from the mailing list.

M

So, thanks to the hills and battery for giving us feedback, we added a lot of stuff regarding security considerations we edit metadata and so on and so on and so on, and the reason why I would want to present that today is I would like to ask the working group to adopt that as a working group item.

M

That's it from my side.

B

Now I would cut the line after Justin.

M

J

So Justin richer. They deleted all the stuff that I thought was a terrible idea from the last document. So that's a huge improvement. The security discussions is going in the right direction. I think it needs a lot more chewing on, but that's what we do here I would support this going forward with the caveat and I raised this in London as well that we that we think about using this response mechanism for other parts of the OAuth protocol. That might also want a signed response.

J

Token endpoints, registration, endpoints, yeah, yeah, oh yeah, we've got a bunch of other places where this, where this patch might also apply, whether we do all that in one document or not, I, don't know or care right now, but I suggest this as a good starting point moving forward and support it thanks.

B

And so we're gonna try to take a home on the mailing list or ask for adoption of the mail a because we don't have time right now. Okay, thank you very much. Everybody Thanks! Thank you to us. Thank you.

M

Pleasant meeting yeah.