Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-05.txt

I, for one, appreciate the title. It's a token swap, fulfilling and in some ways replacing the complicated functionality of an old-school STS, but in a more REST-friendly fashion. OAuth is not RESTful, nor has it ever intended to be so. It's REST-friendly and that's a good thing. Besides: it's

[OAUTH-WG] Small bug in HTTP Signing spec

Just had this bug reported on twitter: https://twitter.com/tcaesvk/status/751225569925144576 It's legit, I'll tweak it in the next draft, whenever that comes along. -- Justin ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinf

Re: [OAUTH-WG] RT treatment in Token Exchange

+1 to the proposed wording change. It's clear and allows for use cases where your inputs aren't as replayable as you might otherwise expect. -- Justin On 7/5/2016 2:15 PM, Brian Campbell wrote: I gave a short presentation about OAuth 2.0 Token Exchange

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

POST will send things to the server, which isn’t desirable if your client is solely in the browser. postMessage is a browser API and not to be confused with HTTP POST. postMessage messages stay (or can stay) within the browser, which is the intent here. — Justin > On Jul 1, 2016, at 4:56 PM,

Re: [OAUTH-WG] Security concern for URI fragment as Implicit grant

The implicit flow was designed for in-browser clients that don’t have a server back-end. In these cases, keeping the data inside the browser entirely is exactly the goal: you don’t want to use query or form parameters because those get sent by the browser back to the server. That was the idea an

Re: [OAUTH-WG] define a client_id JWT claim (in Token Exchange)?

+1 for “cid”, consistent with other JWT claims. — Justin > On Jun 20, 2016, at 5:21 PM, Brian Campbell > wrote: > > There is a somewhat poorly worded open issue in Token Exchange about being > able to represent the client in the token. > > There is currently no standard claim for the clien

Re: [OAUTH-WG] nit RFC 7662 Errata?

It’s definitely a mistake, and I think an errata is the right track for it. Not positive though — chairs? — Justin > On Jun 20, 2016, at 5:02 PM, Brian Campbell > wrote: > > Some good irony in that message as I made a very similar mistake. The "IANA > Considerations RFC 7591 / Token Intros

Re: [OAUTH-WG] Token Exchange's act and may_act claims also registered for Introspection Endpoint responses?

Makes sense to me. — Justin > On Jun 20, 2016, at 2:46 PM, Brian Campbell > wrote: > > The question of if the act and may_act claims defined in Token Exchange > should also be registered/defined for Introspection Endpoint responses was > raised on this list a while back. Not much was said a

Re: [OAUTH-WG] TAuth

I posted about this the other day. What I don't understand is that he's saying people disable TLS checks so he's going to solve it with mutual TLS?  I need to email this guy and learn more about what he's doing.  --Justin  Sent from my phone Original message From: Brock Allen Da

Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

uot; the use means to me that the tokens > for the constrained set of binary protocols which all tend to be in parallel > architecture with web apis anyway. > > Phil > > On May 10, 2016, at 05:57, Justin Richer <mailto:jric...@mit.edu>> wrote: > >> Y

Re: [OAUTH-WG] [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

Of Erik Wahlström > Sent: Tuesday, May 10, 2016 1:44 AM > To: Justin Richer > Cc: Kathleen Moriarty ; Kepeng Li > ; a...@ietf.org; Carsten Bormann ; > Hannes Tschofenig ; > ; cose > Subject: Re: [Ace] [COSE] Call for adoption for > draft-wahlstroem-ace-cbor-web-token-0

Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

We can also call it the “COSE Token”. As a chair of the COSE working group, I’m fine with that amount of co-branding. — Justin > On May 9, 2016, at 9:31 AM, Carsten Bormann wrote: > >> draft-ietf-ace-cbor-token-00.txt; > > For the record, I do not think that ACE has a claim on the term "CBO

[OAUTH-WG] Another OAuth "alternative"

This just passed across my desk, something called TAuth: https://blog.teller.io/2016/04/26/tauth.html Basically, the story is “OAuth is hard, so we made our own thing”. Unfortunately, the new thing requires mutual TLS, non-expiring tokens, and a p

Re: [OAUTH-WG] Another CSRF attack

I’ve not heard this attack spelled out like this, but I know that our client library was explicitly coded to prevent this by remembering the “issuer” of the outgoing request and tying that to the session and state value. — Justin > On May 5, 2016, at 10:13 AM, Daniel Fett wrote: > > We found

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

I agree that we’re getting dangerously close to recommending signed assertions at every step of the process, thereby bypassing HTTP. This was the same mistake that WS-* and SOAP made, let’s not repeat it if we can. — Justin > On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt > wrote: > > Hi

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

OpenID Connect defines a third-party login endpoint for RP's, which is what the AS is acting as in this case: http://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin -- Justin On 4/22/2016 10:50 AM, Fregly, Andrew wrote: Hi George, You have the flow right for how I hav

Re: [OAUTH-WG] Meeting Minutes

I recall +1’ing that idea in the chat. It’s an “updates” to 6819 at least. — Justin > On Apr 18, 2016, at 6:34 PM, Brian Campbell > wrote: > > Yeah, as I recall, there was at least some support around the idea of an > "enhanced OAuth security" document. > > On Sun, Apr 17, 2016 at 2:46 AM

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

gt;> This also necessitates the Client to be able to find out what token type the >> resource requires, perhaps in the unauthorized response web link header at >> the resource in the manner of oauth-meta. >> >> Cheers, >> >> Nat >> >> >>

Re: [OAUTH-WG] Meeting Minutes

That’s correct, we’ve filed an issue in our project to track its eventual implementation: https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/1055 — Justin > On Apr 11, 2016, at 8:21 AM

Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00

+1 for adoption, but please remove the "web" from the name. One of the main features of JSON Web Tokens, from which this is inspired, is that it can be passed without any additional encoding in HTTP headers, parameters, forms, strings, etc. It's built for the "web" from the ground up. The sa

Re: [OAUTH-WG] [scim] Simple Federation Deployment server to server

+1, this seems a better fit for openid. — Justin > On Apr 6, 2016, at 9:05 AM, Brian Campbell wrote: > > OpenID ... ? > > On Wed, Apr 6, 2016 at 9:59 AM, Anthony Nadalin > wrote: > Good question, since SCIM does not really provide an authorization model and >

Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0

I support adoption of this document as a starting point for working group work. — Justin > On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig > wrote: > > Hi all, > > this is the call for adoption of 'Resource Indicators for OAuth 2.0', see > http://datatracker.ietf.org/doc/draft-campbell-oauth-

Re: [OAUTH-WG] Resource Service metadata

But it’s less likely (or less easy?) to have a malicious combination of endpoints in a static configuration. What this all boils down to is managing a set of endpoints as a “thing” that represents an AS (and some would argue associated RS). You can create that set manually or dynamically and fal

Re: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

I'm with George. You can do introspection with no audience restriction. We implemented introspection with only scope restriction from the RS. -- Justin On 3/18/2016 8:50 AM, George Fletcher wrote: I was thinking of goal #2 as addressing the issue of audience in the token. If the RS "authentic

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

The problem here is that the "authority" model built into the URI definition is completely broken by user-hosted content, as we saw in the attack on ESPN and several against Google+ in the last few years. -- Justin On 3/17/2016 2:42 AM, Nat Sakimura wrote: IMHO, list of URIs that represent

Re: [OAUTH-WG] When does RS not require token introspection ?

+1 to all of this. Our reasoning for the JWT+introspection was to allow for an RS to take in tokens from multiple AS, by looking up the issuer in the JWT itself. — Justin > On Mar 15, 2016, at 12:34 PM, Thomas Broyer wrote: > > > > On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

, if you’re putting a person’s information into the client there, you’re doing impersonation. That’s bad, don’t do that. — Justin > On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin wrote: > > Hi Justin > > Many thanks for the quick response. > On 15/03/16 12:53, Justin Richer

Re: [OAUTH-WG] When does RS not require token introspection ?

On 3/15/2016 9:35 AM, Sergey Beryozkin wrote: Hi Justin On 15/03/16 13:18, Justin Richer wrote: And don't forget option 4: look it up in a database because the RS and AS are in the same box. Sometimes I feel like I understand OAuth2 and today I'm feeling like I've no i

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi Sergey, one comment inline On 3/15/2016 9:31 AM, Sergey Beryozkin wrote: Hi John, Justin On 15/03/16 13:12, John Bradley wrote: Access tokens are opaque to the client not the RS. But only if they are self-contained as in the option 1 below, right ? No. They're non-opaque to the RS in all

Re: [OAUTH-WG] When does RS not require token introspection ?

And don't forget option 4: look it up in a database because the RS and AS are in the same box. -- Justin On 3/15/2016 9:12 AM, John Bradley wrote: Access tokens are opaque to the client not the RS. You have three basic design choices. 1 Use a token that the RS can locally validate. JWT or S

Re: [OAUTH-WG] When does RS not require token introspection ?

The access tokens are opaque to the client, not the RS. -- Justin On 3/15/2016 9:01 AM, Sergey Beryozkin wrote: Hi After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

Is Alice the client here (the piece of software), or is Alice the resource owner? If Alice is the resource owner, then you should absolutely not be using the client credentials flow like this. The client credentials flow is designed for cases where the client is acting on its own behalf, not o

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I agree that this is valuable, and not just for PoP. In all honesty, it’s not even really required for PoP to function in many cases — it’s just an optimization for one particular kind of key distribution mechanism in that case. In the years of deployment experience with OAuth 2, I think we’ve r

Re: [OAUTH-WG] Multiple authorization servers for one resource server

a JWT as access token, with > issuer, scopes and basic identity information included seems to solve our > issues. > > Thanks, > Andrea > > > > > 2016-03-13 9:03 GMT+08:00 Justin Richer <mailto:jric...@mit.edu>>: > What we've done in deployments

Re: [OAUTH-WG] Multiple authorization servers for one resource server

Agree with Phil, an additional header is a bad idea. It's not only yet another thing that can be attacked, it's another thing that can get out of sync by the client. Always assume OAuth clients are the dumbest parts of the system. -- Justin On 3/12/2016 2:36 PM, Phil Hunt (IDM) wrote: Right

Re: [OAUTH-WG] Multiple authorization servers for one resource server

What we've done in deployments is to combine JWT and introspection. You have all of your servers issue signed JWTs that include the "iss" (issuer) in the body, signed with the key of the AS. The tokens also include a random "jti" field. The RS submits the token to the introspection endpoint of

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

uld be to do a stable sort on >> parameter names. That is, sort the names, but preserve the order of values >> when a name appears multiple times. …hoping that works with almost all >> frameworks. >> >> -- >> James Manger >> >> From: OAuth [

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

> of the value included somehow (which I’m sure you’ve already thought of). > That’s obviously more complexity and overhead for all scenarios to support > this edge case. > > -Brock > > From: Brock Allen [mailto:brockal...@gmail.com] > Sent: Sunday, February 28, 2016 4:

Re: [OAUTH-WG] HTTP signing and parameter validation

It’s a bit of both and it’s going to be highly specific to the API being protected. The RS should reject a signed request in which a critical parameter is unsigned — some implementations of OpenID 2.0 were susceptible to exactly this kind of attack a number of years ago. We could probably add

Re: [OAUTH-WG] HTTP request signing and repeated query/header keys

In §7.5 we currently have: The behavior of repeated query parameters or repeated HTTP headers is undefined by this specification. If a header or query parameter is repeated on either the outgoing request from the client or the incoming request to the protected resource, that query par

Re: [OAUTH-WG] HTTP signing spec and nonce

for the above reasons (ws-sec msg security, > hawk)... > > — > cheers > Dominick Baier > > On 27 February 2016 at 03:48:00, Justin Richer (jric...@mit.edu > <mailto:jric...@mit.edu>) wrote: > >> I’d be glad to add in a nonce if there’s a compelling

Re: [OAUTH-WG] HTTP signing spec and nonce

I’d be glad to add in a nonce if there’s a compelling reason for it, such as closing a security attack vector. What’s the proposed purpose of the nonce? Is it just to add randomness to the signing base? Or is it to prevent replay at the RS? If the former, the timestamp should add enough of that

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

very spec will not lead the client to >> understand it has the wrong resource server. Rather the fake resource >> service will just have a fake discovery service. The hacker can now >> intercept resource payload as well as tokens because they were able to >> con

Re: [OAUTH-WG] OAuth 2.0 Discovery Location

ferent scopes; sounds like an edge-case to me though; maybe RFC6750 should instead be updated with such a parameter such that an RS could return several WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?) On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <

[OAUTH-WG] OAuth 2.0 Discovery Location

The newly-trimmed OAuth Discovery document is helpful and moving in the right direction. It does, however, still have too many vestiges of its OpenID Connect origins. One issue in particular still really bothers me: the use of “/.well-known/openid-configuration” in the discovery portion. Is this

[OAUTH-WG] PoP Key Distribution

In PoP Key Distribution, I’m trying to figure out the full set of expectations that the client and AS will need to handle across different systems. From what I gather, we’ve got at least these: Client provides public key: - Client stores keypair - Server stores public key

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

ld be my preference. > > -- Mike > From: Justin Richer <mailto:jric...@mit.edu> > Sent: ‎2/‎13/‎2016 11:11 AM > To: Phil Hunt <mailto:phil.h...@oracle.com> > Cc: <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] Authentication Method Reference Values: Call for &

Re: [OAUTH-WG] Authentication Method Reference Values: Call for Adoption Finalized

Can we just do that, then? Seems to be the easiest way to address various needs and concerns. — Justin > On Feb 13, 2016, at 11:08 AM, Phil Hunt (IDM) wrote: > > Yes > > Phil > > On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net > "

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

ean different things depending on the protocol, >>>>>>> and not every protocol needs per user discovery. >>>>>>> >>>>>>> John B >>>>>>>> On Feb 9, 2016, at 7:39 PM, Phil Hunt (IDM) >>>>>>>

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

icatins just add to > that? > > I prefer not to change the file name if we are going for one config file, but > if we do one alias/link is probably not the end of the world, as I doubt > people will ever remove openid-configuration one if they have it now. > > John B. >

Re: [OAUTH-WG] Initial OAuth working group Discovery specification

Mike, thanks for putting this up. I would like to propose for two changes that have been brought up before: 1) The wholesale removal of section 2, Webfinger lookup. 2) The changing of "/.well-known/openid-configuration” to "/.well-known/oauth-authorization-server” or something else not openid

Re: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2

There's already support for this, but just a quick reminder to the working group that we already hint at this capability in RFC7951: In some cases, authorization servers MAY choose to accept a software statement value directly as a client identifier in an authorization request, without

Re: [OAUTH-WG] OAuth 2.0 Device Flow: Call for Adoption Finalized

Dynamic client registration makes provisioning secrets much easier on devices like this. When it was originally written, the target was a public native application, where every copy would've gotten the same secret at manufacture time rendering it not as secret. We've got good ways around that r

Re: [OAUTH-WG] OAuth 2.0 for Native Apps: Call for Adoption Finalized

I’d like to note that when Tony brought up it being Experimental on the list, several of us (myself included) pointed out that Informational is the correct designation for this specification. — Justin > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig > wrote: > > Hi all, > > On January 19th

Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

stuck. > > Since there needs to be "space" on the author list I would at least > remove myself from the author list of the HTTP signing document. > > Ciao > Hannes > > PS: I saw your post regarding the PoP implementation. Thanks for doing > that work. I

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

+1, if we define a webfinger/rel at all. I would rather we just define the service discovery document, the thing that lives under .well-known. — Justin > On Feb 4, 2016, at 4:01 AM, Roland Hedberg wrote: > > +1 > >> 4 feb 2016 kl. 08:10 skrev Phil Hunt : >> >> +1 for adoption. >> >> Howe

Re: [OAUTH-WG] OAuth PoP Implementation

Hi Erik, responses inline. On 2/4/2016 4:20 AM, Erik Wahlström wrote: Hi, Good work Justin. I’ve also implemented (parts) of PoP tokens for the ACE WG oauth2 draft and made a lot of the same assumptions. See below. On 03 Feb 2016, at 23:47, Justin Richer <mailto:jric...@mit.edu>&

[OAUTH-WG] OAuth PoP Implementation

Hi Everyone, I recently decided to put together an end to end implementation of at least part of the proposed OAuth specs. I haven’t seen any other implementations of the whole system, so I wanted to see how viable this whole idea really. It’s done in Node.js (using Express.js) and it’s on GitH

Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE

would be the > pre-requisite for interop. That's what I wanted to point out. > > kind regards, > Torsten. > > Am 31.01.2016 um 14:47 schrieb Justin Richer: >> It would be for client authentication to the revocation endpoint, if the >> client were to use

Re: [OAUTH-WG] Call for Adoption

we would have to do the > discovery. > > Nat > > 2016年1月28日(木) 5:45 Justin Richer mailto:jric...@mit.edu>>: > Unless I’m missing something, requiring the authority section to match > discounts attackers being able to deploy executable code on a path. This kind > of hol

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I propose we rename this the “Random ASs Attack”. — Justin (only half joking) > On Jan 27, 2016, at 8:07 AM, Nat Sakimura wrote: > > Yup. > > For the RPs that would deal with valuable data, I also recommend it to become > HTTPS only. This will effectively close the hole for the AS Mix-Up.

Re: [OAUTH-WG] Call for Adoption

Unless I’m missing something, requiring the authority section to match discounts attackers being able to deploy executable code on a path. This kind of hole was exploited in a number of Facebook hacks. Yes I’m aware that those were dealing with redirect URIs but we’re talking about the same kind

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

ental auth > >> isn't really viable. > >> > >> Regarding security: don't do this for non-confidential clients where you > >> can't verify the identity of the app by the redirect (e.g. a localhost > >> redirect to an installed app). > >&g

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

+1 > On Jan 25, 2016, at 1:39 PM, George Fletcher wrote: > > So now, in addition to the dynamic client registration spec, the client would > need to support OAuth2 Discovery. > > I guess my concern is that it feels like we are adding a lot of little things > to try and mitigate these attacks

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

7;t feel strongly about it either; it was just what was agreed at first. > Since no-one actually came up with even a hypothetical attack I guess it > makes sense to revert that decision. > > Hans. > > On 1/21/16 7:58 PM, Justin Richer wrote: >> Thank you for removing s

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

up in Germany. I want people to know it was changed, so they can > provide feedback if they feel strongly. > > John B. > >> On Jan 21, 2016, at 3:58 PM, Justin Richer > <mailto:jric...@mit.edu>> wrote: >> >> Thank you for removing state hashing and pleas

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Thank you for removing state hashing and please don’t add it back. It’s security theater, and that’s giving it the benefit of the doubt. Remember, this is being sent in a request where other parameters (code, client_id, client_secret, redirect_uri) are all sent plain over TLS as well. Either co

Re: [OAUTH-WG] Call for Adoption

erely, > -- Mike >   <> > From: Nat Sakimura [mailto:sakim...@gmail.com] > Sent: Wednesday, January 20, 2016 11:17 PM > To: Mike Jones ; William Denniss > ; Justin Richer > Cc: oauth@ietf.org > Subject: Re: [O

Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

the "amr" claim, which is registered in the >> OAuth-established registry at http://www.iana.org/assignments/jwt, is >> squarely within the OAuth WG's mission for the creation and stewardship of >> JWT. >> >> -- Mike &

Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values

Just reiterating my stance that this document detailing user authentication methods has no place in the OAuth working group. — Justin > On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig > wrote: > > Hi all, > > this is the call for adoption of Authentication Method Reference Values, see > http

Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

Tony, that doesn’t make sense. An experimental draft would still be a WG draft, and even then this doesn’t match any of the qualifications of “experimental” by IETF definition. It’s arguable whether it be marked “informational” or “standard” since it’s describing best practices more than protoco

Re: [OAUTH-WG] Call for Adoption

+1 Inline discovery and pre-configured discovery (ie, .well-known) should at the very least be compatible and developed together. It's the pre-configured discovery document that's at the root of the mix-up attack in the first place. -- Justin On 1/19/2016 10:30 PM, Nat Sakimura wrote: Just

Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps

Well that’s interesting: I was unaware I was being removed as the author of the HTTP signing draft. This is especially surprising after the presentation I gave at Yokohama about this topic. The draft hasn’t been updated because there’s not really been any discussion on it here in the group to dr

Re: [OAUTH-WG] best practice for Native app + state param?

I think there’s no advice because it’s not different: you should still be using the state parameter. Just use a random value with high enough entropy, which is also what most web applications do (the advice in the spec is weird and I think a remnant of Bradley making things too complicated in hi

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

Yes, this is common practice. Give the user the option to remember the decision. This is known as "trust on first use", or tofu. Our server, MITREid Connect, implements this as do many others.  -- Justin / Sent from my phone / Original message From: Sergey Beryozkin D

Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection)

All the values in the token introspection response are optional, except for “active”. If you don’t have anything to say about a particular aspect of the token, or can’t say it to the software that’s asking, then you generally leave it out of the response. — Justin > On Jan 16, 2016, at 11:02

Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

+1 to Brian’s point, and points to Mike for promising to address this. I wasn’t able to attend the meeting in Darmstadt, but I’ve been following the discussion and original papers. Let’s take this one piece at a time and not overreach with a solution. In particular, the whole “late binding disc

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

ndependentid > www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> >> On Dec 1, 2015, at 11:21 AM, Justin Richer > <mailto:jric...@mit.edu>> wrote: >> >> You’ve got “The token remains opaque to t

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

ndentid >> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com >> <mailto:phil.h...@oracle.com> >>> On Dec 1, 2015, at 10:28 AM, Kathleen Moriarty >>> >> <mailto:kathleen.moriarty.i...@gmail.com>> wrote: >>>

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

t, however saying integrity protected, may be better than >> signed. May people will argue that HMAC or encryption with sender >> verification is not signature. >> >> Good point, I also prefer integrity protected. Are we all good with this >> now? I'd like to

Re: [OAUTH-WG] OAuth Discovery

Those should be handled separately if they’re to be added to discovery. — Justin > On Nov 26, 2015, at 9:30 AM, Vladimir Dzhuvinov > wrote: > > Good work, Mike, John, Nat! > > I see that the introspection and revocation endpoints are included now > (they've been missing in OpenID discovery)

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

at tokens are opaque then the requirement that >>> tokens be signed must be removed from the threat mitigation requirements. >>> >>> And the paragraph in sec 5 that brian was concerned about be restored. >>> >>> Phil >>> >>> On

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

ssed in the > access token. > There is commonly user and or role info that they want to protect. If PoP > required the tokens to be readable/verifiable by the client then it would be > a non starter for privacy reasons lots of places. > > John B. > > >> On Nov

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

from Kathleen and Erik raised since >>>> the last draft. >>>> >>>> It may not include some of the discussion from yesterday/today. I will >>>> add that as the group decides. >>>> >>>> Cheers, >>>> >>>> Phil >&g

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

>> and verify the token. It's an assumption to simplify the examples that >> follow and still the token is opaque to the client. I reread the whole draft >> (reluctantly) and there's nothing that says the token has to be non-opaque >> to the client. And it does

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

ww.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> >> On Nov 25, 2015, at 9:33 AM, Justin Richer > <mailto:jric...@mit.edu>> wrote: >> >> The token doesn’t have to be signed and the client doesn’t have to verify >> the signa

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-architecture-06.txt

; phil.h...@oracle.com <mailto:phil.h...@oracle.com> >> >> > On Nov 24, 2015, at 12:05 PM, internet-dra...@ietf.org >> > <mailto:internet-dra...@ietf.org> wrote: >> > >> > >> > A New Internet-Draft is available from the on-line Interne

Re: [OAUTH-WG] AD review of draft-ietf-oauth-proof-of-possession

I suggest removal of the reference to bearer tokens in this section, since that seems to suggest that this is what the RS should do in such a case. What’s really going to happen is that an RS is going to get a request with this token and it’s going to have to figure out how to deal with it. If t

Re: [OAUTH-WG] RFC 7662 OAuth 2.0 Token Introspection: token_type

It should be left off of the the response. We probably should’ve had more examples for that. In general though it’s going to be the protected resource introspecting tokens, and they usually don’t have refresh tokens. We allow other kinds of tokens (ID Tokens, Refresh Tokens, etc) but the canonic

Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05

t PoP with the resource server. This is a new issue regarding refresh tokens that John and Hannes are raising. Phil @independentid www.independentid.com phil.h...@oracle.com On Nov 23, 2015, at 12:11 PM, Justin Richer wrote: Access tokens and refresh tokens provide different attack surf

Re: [OAUTH-WG] Adding use case to draft-ietf-oauth-pop-architecture-05

Access tokens and refresh tokens provide different attack surfaces. The refresh token is *potentially* a one-time-use token, but not necessarily so. Confidential clients are still subject to having their credentials stolen across HTTP Basic, but that’s where things like OIDC’s “private_key_jwt”

Re: [OAUTH-WG] A review of draft-ietf-oauth-pop-architecture-05

I agree with added "For example" in a few places. It's not normative it's informational here.  -- Justin / Sent from my phone / Original message From: Phil Hunt Date: 11/19/2015 11:28 AM (GMT-06:00) To: Erik Wahlström neXus Cc: ""

Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

By the way, folks: If people disagree with COSE being a rewrite of JOSE, they should speak up in the COSE working group and say so. — Justin > On Nov 18, 2015, at 2:01 AM, Hannes Tschofenig > wrote: > > Hi Bill, > > Ø Is a data type mapping form JWT to

Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

Thanks very much, Eric. As we promised in Yokohama, the chairs of the COSE working group are currently running a consensus call thread about this very topic, and I’d encourage others to join that discussion. The thread starts here: http://www.ietf.org/mail-archive/web/cose/current/msg00747.html

Re: [OAUTH-WG] aud, JAR, PoP key distro, etc. (was Re: IETF 93 OAuth WG Meeting Minutes)

I was considering preparing an "extended scopes" concept draft to define both a target parameter (what we're using "aud" for) as well as a temporal parameter, to sit beside scope which is more naturally an "extent of permission". We need the audience bit for HEART, and I know others that do

[OAUTH-WG] UMA Resource Set Registration

As brought up in the F2F today in Yokohama, the UMA Resource Set Registration document is here: https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html The ID has expired and is out of sync with the Kantara document. — Justin ___ OAuth m

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

gt; > -Original Message- > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, November 4, 2015 8:43 PM > To: Justin Richer > Cc: > Subject: Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec > addressing final shepher

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

I’d argue that it’s best practice, and in line with other parts of OAuth, if we assume the server generates it in the normal case (issuer -> presenter). Client generated token keys should be an exception, especially in the asymmetric case. — Justin > On Nov 5, 2015, at 1:32 PM, John Bradley w

Re: [OAUTH-WG] OAuth 2.0 Introspection RFC Issues

Hi Michael, Thanks for the comments. First off, the text of an RFC is fixed and cannot be changed. The spec can only be altered with a new document that obsoletes RFC7662, which would have to go through the working group process again from the very beginning. Authentication is required but we’

Re: [OAUTH-WG] some WGLC comments on draft-ietf-oauth-jwsreq-06

The errata/update version of Connect’s registration spec need to register a bunch of stuff in the Dyn-Reg IANA registry, but I don’t think that’s been done yet. — Justin > On Oct 27, 2015, at 3:41 PM, Brian Campbell > wrote: > > Sakimura-san, Senior Bradley, and distinguished members of the

<    1   2   3   4   5   6   7   8   9   10   >