Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

oken’s expiry? Can’t they > just use the refresh token and see? Either way it’s a single round trip to > the AS and the client gets the same answer with the same recovery code path. > > — Justin > > On Mar 4, 2020, at 2:01 PM, Bill Jung < > bjung=40pingidentity@dmarc.ietf

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

ccess Token introspection to RS only. But then is that the right thing to do even? Surely some clarification will eliminate the time spent on unnecessary discussion among developers. <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Bill Jung

Re: [OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

Yes, actually the term "protected resource" is awkward. It is the resource server's jog to introspect tokens to protect those protected resources. <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Bill Jung Manager, Response Engineeri

[OAUTH-WG] OAuth 2.0 Token Introspection in RFC7662 : Refresh token?

oken" value returned from the token endpointas defined in OAuth 2.0 [RFC6749], Section 5.1."* So looks like a refresh token is allowed for this endpoint. <https://www.pingidentity.com>[image: Ping Identity] <https://www.pingidentity.com> Bill Jung Manager, Response Engineeri

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

-- Mike > > -Original Message- > From: OAuth On Behalf Of Bill Burke > Sent: Thursday, May 17, 2018 2:11 PM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt > > My personal opinion is that I'm

Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt

s strictly prohibited.. If you have >> received this communication in error, please notify the sender immediately >> by e-mail and delete the message and any file attachments from your >> computer. Thank you. >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited.. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you. > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] public clients and token exchange

sword credentials grant. For code to token, this means the public client had a valid redirect uri. For password credentials grant, the client was trusted enough to obtain user credentials. -- Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org

Re: [OAUTH-WG] What Does Logout Mean?

Sure, sort of. Though, we would have never implemented these extensions if back channel logout didn't exist as a concept and requirement. Its all in the sometimes ugly business of supporting application developers who have a variety of deployment requirements and

Re: [OAUTH-WG] What Does Logout Mean?

he local session id. As a IDP vendor, you have to support all these types of clients. Telling developers that they are just going to have to manage this themselves is not really an option if you want adoption. Bill ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What Does Logout Mean?

> > Then,isn't any backchannel logout specification more of a framework than an actual protocol? -- Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] What Does Logout Mean?

On Wed, Mar 28, 2018 at 1:40 PM, Richard Backman, Annabelle < richa...@amazon.com> wrote: > I'm reminded of this session from IIW 21 > . ☺ > I look forward to reading the document distilling the various competing use > cases and

Re: [OAUTH-WG] What Does Logout Mean?

d at http://self-issued.info/?p=1804 and as > @selfissued. > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

lar purpose (like a Facebook access token for access to > Facebook APIs) is used implicitly for a different purpose (like getting a > different access token for access to APIs in a different domain). > > > > On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke wrote: >> >> On F

Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

't know how far in the process the token exchange draft was. In the least, I wanted to make the WG aware of our work. We have a decent and growing user base with a problem looking for a solution and we're going to get a lot of feedback on what we've implemented. At least from o

[OAUTH-WG] [token-exchange] Parameters to support external token exchange

ent. This 'redirect_uri' must be a registered and valid redirect uri for the forwarding client. After the redirect, the client can then make an exchange request. For error conditions, the redirect_uri may by forwarded to with an additiona

Re: [OAUTH-WG] Token Exchange Implementations

> OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recommendations for browser-based apps

y happening behind > the scenes? > > -- Neil > > On 20 Sep 2017, at 02:31, Jim Manico wrote: > > Not always, Bill. There is a new standard called "same site cookies" or > "first party cookies" that allows you to programmatically remove this risk > in s

Re: [OAUTH-WG] Recommendations for browser-based apps

t; >> Except a refresh token is not purely bearer. The client is required to >> authenticate to use it. >> >> Phil >> >> > On Sep 19, 2017, at 2:33 PM, Bill Burke wrote: >> > >> > I'd be curious to the response to this too. >> &g

Re: [OAUTH-WG] Recommendations for browser-based apps

th PKCE in SPAs, if you have some recommendations for good blog posts > I would be grateful. > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

oauth-token-exchange-09#section-3>) so the issuer is the given STS in that case. Cross domain is possible by use of other token types that are not opaque to the STS where the issuer can be inferred from the token. On Fri, Jul 28, 2017 at 3:27 PM, Bill Burke <mailto:bbu...@redhat.com>>

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

issuer id can be any URL. IMO, adding optional "subject_token_issuer" and "requested_issuer" parameters only clarifies and simplifies the cross-domain case. If you don't like "issuer" maybe "domain" is a better word? Thanks for replying, Bill

Re: [OAUTH-WG] [token-exchange] exchanging between issuers/domains

and architectures. On 7/26/17 6:44 PM, Bill Burke wrote: Hi all, I'm looking at Draft 9 of the token-exchange spec. How would one build a request to: * exchange a token issued by a different domain to a client managed by the authorization server. * exchange a token issued by

[OAUTH-WG] [token-exchange] exchanging between issuers/domains

thing like a "requested_issuer" identifier? Seems that audience is too opaque of a parameter for the authz server to determine how to exchange the token. Thanks, Bill ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Short lived access token and no refresh token

For browser apps, implicit flow provides an access token but no refresh token. For non-browser apps only client credentials grant doesn't supply a refresh token. As for token access times, I believe only extensions to OAuth define those types of capabilities. i.e. OpenID Connect defines a "m

Re: [OAUTH-WG] oauth with command line clients

57SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=j2jP9OSVjttUWWQMazHXMhLBvLqfXsFJB6GEOh_Mv9k&s=Zn85klv9a00I3Uo74zgqAelgrFUFQc72PdFwg4gkECQ&e=> @aaronpk <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_aaronpk&d=DwMDaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY0

Re: [OAUTH-WG] oauth with command line clients

e. A colleague pointed me to SASL + HTTP [1], but not sure if that's what I'm looking for. Thanks everybody, Bill [1] https://tools.ietf.org/html/draft-nystrom-http-sasl-09 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] oauth with command line clients

rect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user. Aaron Parecki aaronparecki.com <http://aaronparecki.com> @aaronpk <http://twitter.com/aaronpk> On Sun,

[OAUTH-WG] oauth with command line clients

dy has put some thought into. Hope I'm making sense here. Thanks, Bill Burke Red Hat ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Google's use of Implicit Grant Flow

For our IDP [1], our javascript library uses the auth code flow, but requires a public client, redirect_uri validation, and also does CORS checks and processing. We did not like Implicit Flow because 1) access tokens would be in the browser history 2) short lived access tokens (seconds or min

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

alue.  It would be better if this were not dependent on by-hand configuration. -bill On Tuesday, January 12, 2016 8:03 PM, Justin Richer wrote: +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 foll

Re: [OAUTH-WG] OAuth Discovery

I think it is more likely that the flow for the user will be that they know an RS and the RS provides some reference to the AS.  The RS might well consume a generic lookup flow though.  We do need the "updated webfinger thing" for users as a generic though. The WF type thing for a generic user

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

> It is fair to say that the threats and mitigations from bearer tokens also > apply to PoP tokens.> PoP tokens add additional key information that must > also be protected along with the other > information in a access token. THis doesn't really work because for example transport security to pr

Re: [OAUTH-WG] OAuth Discovery

Can you elaborate on the advantage of having a separate parallel spec to OpenID Discovery? On Wednesday, November 25, 2015 3:37 PM, Mike Jones wrote: I’m pleased to announce that Nat Sakimura, John Bradley, and I have created an OAuth 2.0 Discovery specification.  This fills a hole

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

Is a data type mapping form JWT to CBOR sufficient then? On Monday, November 16, 2015 11:26 PM, Hannes Tschofenig wrote: #yiv5390846737 #yiv5390846737 -- _filtered #yiv5390846737 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5390846737 {font-family:Tahoma;panos

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

If there are structural differences in what CBOR can support it would be worthwhile to note that.  Examples of things supported in JWT that you can't do in CBOR could be very helpful to implementers. On Monday, November 16, 2015 1:32 PM, William Denniss wrote: You raise some good

Re: [OAUTH-WG] PoP Architecture - IPR Confirmation

Further, not version specific.  I am aware of now IPR related to this document in any version. On Tuesday, October 20, 2015 10:01 AM, Bill Mills wrote: I am still aware of no IPR related to  https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt On Tuesday

Re: [OAUTH-WG] PoP Architecture - IPR Confirmation

I am still aware of no IPR related to  https://www.ietf.org/id/draft-ietf-oauth-pop-architecture-02.txt On Tuesday, October 20, 2015 12:37 AM, Hannes Tschofenig wrote: Hi Bill, sorry to bother you again regarding this IPR issue but when I search through the OAuth mailing list

Re: [OAUTH-WG] Auth Server / Resource Server Coordination

Centralizing the user auth yes, it doesn't even have to be multiple types of RS for this to win.  It reduces your attack surface and allows your auth stack to be separate from your app stack are two of the good things.  Auth is a specialized thing and hard to do right, and pulling it down to a m

Re: [OAUTH-WG] Auth Server / Resource Server Coordination

You're generally right on track.  The RS needs to understand the token format and needs to trust the AS.  You bring in all the "hwo do 2 entities maintain a trust relationship in computing thing" here, because the RS needs to trust the AS.  You can use a JWT (a common choice) as your token forma

Re: [OAUTH-WG] PoP document: IPR Confirmation

I am aware of no IPR issues for this document. Regards, -bill On Wednesday, September 30, 2015 3:53 AM, John Bradley wrote: I confirm that I know of no IPR that reads on this specification. John Bradley’ On Sep 30, 2015, at 7:03 AM, Kepeng Li wrote: Hi Mike, John and Hannes,I am

Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

And thank you Hannes for all the guidance and being a great collaborator on this! And to the WG, chairs, and shepherds, we did something good here. Thank you all for the review, attention, time, and your help as well. -bill -Original Message- From: Mike Jones Sent: Tuesday

Re: [OAUTH-WG] Fwd: RFC 7628 on A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth

And thank you Hannes for all the guidance and being agreat collaborator on this!   And to the WG, chairs, and shepherds, we did somethinggood here.  Thank you all for the review,attention, time, and your help as well.   -bill On Tuesday, September 1, 2015 9:04 AM, Torsten

Re: [OAUTH-WG] Lifetime of refresh token

You don't need to put an expiration on the refresh token.  You get to see that refresh token every 5 minutes anyway.  If you ever want to force the client to re-auth just use policy on the AS.  Nothing will be broken with what you are doing though. On Friday, August 28, 2015 7:21 AM, Don

Re: [OAUTH-WG] Lifetime of refresh token

You could have a refresh token that never expires.  Having to use the refresh token to get a new access token gives you a single control point to allow checking whether that refresh token should still be valid.  Means the RS doesn't have to do that stuff. On Monday, August 24, 2015 8:09

Re: [OAUTH-WG] Is it allow to add custom attribute to access token response?

And as John said, if you are doing user authentication use OpenID instead. On Friday, August 21, 2015 9:38 AM, John Bradley wrote: Yes going the unregistered route it is probably best to use a name in you namespace eg “com.example:username”. On Aug 21, 2015, at 1:34 PM, William De

Re: [OAUTH-WG] Is it allow to add custom attribute to access token response?

You can do your own extension in your own app, just don't expect anyone else to use it.   Not understanding why you want this though, because you already had a username in the request so the client should know. Take a look at the Token Introspection stuff, it might solve this for you a different

Re: [OAUTH-WG] Question about usage of OAuth between servers

Using Bearer tokens with refresh tokens is a valid use case for server-to-server and has the same nice properties that is does for users, in that it applies a single control point for revoking access.  Using Bearer tokens has very different security properties than OAuth 1.0a and you should ca

Re: [OAUTH-WG] XARA vulnerability Paper and PKCE

le of being sender confirmed.  Nat 2015-06-18 23:47 GMT+09:00 Bill Mills : PKCE solves a subset of this, but not the general case.  It doesn't solve the FB example in the paper where the FB token is passed between apps locally. It is a clear win for the OAuth code flow for example though.

Re: [OAUTH-WG] XARA vulnerability Paper and PKCE

PKCE solves a subset of this, but not the general case.  It doesn't solve the FB example in the paper where the FB token is passed between apps locally. It is a clear win for the OAuth code flow for example though. On Thursday, June 18, 2015 7:31 AM, Nat Sakimura wrote: Hi OAuthers

Re: [OAUTH-WG] redircet_uri matching algorithm

+1 On Thursday, May 21, 2015 12:29 PM, Mike Jones wrote: +1 I vehemently concur that that working group should stay completely clear of facilitating this insecure practice.                 -- Mike -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf O

Re: [OAUTH-WG] redircet_uri matching algorithm

ult to implement and the state param larger and more complex. prefix matching seems like it would be a very common thing that an auth server supports and clients would want to have. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

Re: [OAUTH-WG] JWT binding for OAuth 2.0

Yes, Microsoft supports this on Hotmail/Outlook.com and the Outlook client supports it. On Tuesday, April 14, 2015 2:42 PM, John Bradley wrote: There is a OAuth binding to SASL  https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-19 Google supports it for IMAP/SMTP,  I think th

Re: [OAUTH-WG] Token Chaining Use Case

hpDefault {font-size:10.0pt;} _filtered #yiv7149031579 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv7149031579 div.yiv7149031579WordSection1 {}#yiv7149031579 Bill,  Thanks for the clarification.  How do you propose the AS deal with the following RFC6749 Section 6. Refreshing an Access Token requirement?

Re: [OAUTH-WG] Token Chaining Use Case

in spec if there are derivative internal scopes not in the original scope list though.  This doesn't support internal scopes for partitioning that the AS doesn't know about. An internal AS providing chaining would need to understand the AT just as the RS does, and treat it as a refresh

Re: [OAUTH-WG] Token Chaining Use Case

: Thursday, March 26, 2015 4:22 PM To: Bill Mills Cc: Subject: Re: [OAUTH-WG] Token Chaining Use Case  +1. We all have to change production code when non final specs evolve.   I particularly don't see this as a valid argument at the start of a standards discussion.  Phil On Mar 26, 2015, at

Re: [OAUTH-WG] Token Chaining Use Case

Requiring a round trip to the AS is going to have a huge headwind for implementation in high performance environments. I think we need to pursue something like what Phil is talking about where the intermediary server has it's own credential or authority.  On Thursday, March 26, 2015 1:25

Re: [OAUTH-WG] Token Chaining Use Case

ike a refresh token being presented by the one it was issued to, this token is being presented by someone it was presented to.  The feeling is close, but not quite the same in either development or assumptions. -- Justin / Sent from my phone / Original message From: Bill Mills Date

Re: [OAUTH-WG] Token Chaining Use Case

So why can't the access tokne simply be re-used as a refresh token?  Why would it need a new grant type at all? On Thursday, March 26, 2015 11:31 AM, Justin Richer wrote: As requested after last night’s informal meeting, here is the token chaining use case that I want to see repr

Re: [OAUTH-WG] OAuth Token Swap (token chaining)

process to obtain an access token on behalf of the user before it can invoke on the STS? Or can it be granted tokens for any user out of band without user consent or user authorization? -- Bill Burke JBoss, a division of Red Hat http://bill.burkec

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

signed AT. >From a enterprise policy point of view having a REST like STS functionality is >I think the right long term answer. John B. On Mar 17, 2015, at 6:32 PM, Bill Mills wrote: In practice one of the drawbacks of the Oauth 1.0a tokens was that they were not proxyable and so a conn

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

ect rights and optionally binding it to a new PoP key. John B. On Mar 17, 2015, at 6:14 PM, Bill Mills wrote: Yes.  There's still the open question of whether/how PoP tokens can be proxied internally within a site though.  If they can be proxied then it goes back to unsolved.

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

Yes.  There's still the open question of whether/how PoP tokens can be proxied internally within a site though.  If they can be proxied then it goes back to unsolved. On Tuesday, March 17, 2015 2:12 PM, John Bradley wrote: Or by OAuth 2 PoP.     On Mar 17, 2015, at 6:00 PM,

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

token formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we might want to think about documenting it in it's own mini spec, if I understood him correctly. I think that may not be a bad idea as we are also planning on using it in NAPPS

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

s have the client say what RS it is trying to access explicitly (The "aud" parameter), and including an audience in the AT.  to protect against malicious RS. PoP is the step up that also protects against tokens being intercepted and replayed by another client. John B. On Mar 17, 2015,

Re: [OAUTH-WG] Standard URL parameter for mitigating RFC6819's threat 4.6.4?

This may have been hashed out already and I missed it, but "aud" just becomes another kind of scope, correct? On Tuesday, March 17, 2015 8:50 AM, John Bradley wrote: You could do that, but it is probably safer for the AS to know what RS it can issue tokens for and refuse to issue

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

675WordSection1 {}#yiv6169713675 In this use case RS and AS could be implemented and operated by different providers, MTI solves the interop issue.   -Tiru   From: Bill Mills [mailto:wmills_92...@yahoo.com] Sent: Monday, March 09, 2015 11:10 AM To: Tirumaleswar Reddy (tireddy); Hannes Tschofenig;

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

{color:purple;text-decoration:underline;}#yiv3556672566 span.yiv3556672566EmailStyle17 {color:#1F497D;}#yiv3556672566 .yiv3556672566MsoChpDefault {} _filtered #yiv3556672566 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv3556672566 div.yiv3556672566WordSection1 {}#yiv3556672566 Hi Bill,   Can you please provide more

Re: [OAUTH-WG] Fwd: [saag] tram draft - anyone willing to help out?

I do not believe making any specific key distribution MTI is aproprpiate. On Sunday, March 8, 2015 8:06 PM, Tirumaleswar Reddy (tireddy) wrote: Hi Hannes, http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-01#section-5.3 discusses long-term secret shared by the authorizat

[OAUTH-WG] http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-02

Hannes, Please update my e-mail to wimi...@microsoft.com and my affilliation to Microsoft in the next draft. Thanks, -bill___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] AD review of Draft-ietf-dyn-reg

t; OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>> >> https://www.ietf.org/mailman/listinfo/oauth > > > > ___ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > -- Best regards, Kathleen ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-spop-10

I was OK with SHOULD because there's no firm measure of "enough entropy".   Whether it's SHOULD or MUST is moot without some way to quantify it. On Wednesday, February 18, 2015 1:27 AM, Nat Sakimura wrote: Hi Hannes, The reason I have put SHOULD there instead of MUST is that there

Re: [OAUTH-WG] user impersonation protocol?

nilla OAuth) or if you really do need impersonation. You may be able to get the desired results with less complexity that way. -- Justin / Sent from my phone / Original message ---- From: Bill Burke Date:02/16/2015 10:20 AM (GMT-05:00) To: Bill Mills , Justin Richer , oauth

Re: [OAUTH-WG] user impersonation protocol?

t from my phone / Original message From: Bill Burke Date:02/16/2015 10:20 AM (GMT-05:00) To: Bill Mills , Justin Richer , oauth Cc: Subject: Re: [OAUTH-WG] user impersonation protocol? Yeah, I know its risky, but that's the requirement.  Was just wondering if there was any prot

Re: [OAUTH-WG] user impersonation protocol?

tocol work comes in...If it was just a single IDP managing everything, then it would just be an internal custom IDP feature. Thanks all. On 2/16/2015 12:37 AM, Bill Mills wrote: User impersonation is very very risky. The legal aspects of it must be considered. There's a lot of work to

Re: [OAUTH-WG] user impersonation protocol?

stin / Sent from my phone / Original message From: Bill Burke Date:02/15/2015 10:55 PM (GMT-05:00) To: oauth Cc: Subject: [OAUTH-WG] user impersonation protocol? We have a case where we want to allow a logged in admin user to impersonate another user so that they can visit differe

[OAUTH-WG] user impersonation protocol?

some other IETF or even Connect effort that would support something like this? Thanks, Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] code flow for browsers?

. -bill  ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confusion on Implicit Grant flow

x27;s request and not replayed from another session. Why would you need the nonce if the IDP guarantees that the code can only be used once? The code, state, and redirect-uri are all validated by the IDP with the access token request. Bill -- Bill Burke JBoss, a division of Red Hat

Re: [OAUTH-WG] Confusion on Implicit Grant flow

onseModes>. Yeah, and it looks like you can use it for anything. It only defines default modes for various response types (code, token, etc.) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ___ OAuth mailing list OAuth@ie

Re: [OAUTH-WG] Confusion on Implicit Grant flow

;. Thanks for pointing this out! Thanks for all the help. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Confusion on Implicit Grant flow

rely solely on the registered redirect URI for security, but implicit has fewer hopes and is more friendly to JS. John B. On Feb 9, 2015, at 5:50 PM, Bill Burke wrote: If you don't have a client secret, why is Javascript-based auth code grant flow more risky? We also require SSL

Re: [OAUTH-WG] Confusion on Implicit Grant flow

scrypt, then you are probably more at risk using code than implicit. Implicit is risky because running a OAuth client in the browser is risky. Using code in that case makes it no better, and arguably worse. Perhaps I don't understand the environment. John B. On Feb 9, 2015, at 5:05 PM, Bill

Re: [OAUTH-WG] Confusion on Implicit Grant flow

__ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- B

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt

Ah, BNF builtin parser error, that's 42*128.  I had parsed that as 128unreserved as the name. On Thursday, February 5, 2015 12:47 PM, John Bradley wrote: We are discussing the minimum size,  the max is currently 128 characters. On Feb 5, 2015, at 5:11 PM, Bill Mills wrot

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-09.txt

Is there a compelling reason to make that length fixed?   On Thursday, February 5, 2015 10:10 AM, Brian Campbell wrote: 22-chars (128 bits) as a lower limit seems just fine for this case. "ccm" works for me but I don't feel strongly about it either way. On Thu, Feb 5, 2015 at 9:

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

7.2 --  "If the server does not support PKCE, it does not generate error." should read "If the server does not support PKCE it does not generate an error." Otherwise read to go in my opinion. On Wednesday, January 21, 2015 6:23 PM, "internet-dra...@ietf.org" wrote: A New Internet-D

Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

ards Sebastian Ebling Von: OAuth [mailto:oauth-boun...@ietf.org] Im Auftrag von Bill Mills Gesendet: Montag, 29. Dezember 2014 18:46 An: oauth@ietf.org Betreff: Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18 No other comments on this?  Any "It's ready to go."?

Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

Thank you both for the feedback. On Tuesday, December 30, 2014 5:28 AM, John Bradley wrote: I have been tracking it.  It is ready. Sent from my iPhone > On Dec 15, 2014, at 2:33 PM, Benjamin Kaduk wrote: > > Hi all, > > There may be some interested parties over here; please fee

Re: [OAUTH-WG] Fwd: [kitten] WGLC of draft-ietf-kitten-sasl-oauth-18

No other comments on this?  Any "It's ready to go."? On Monday, December 15, 2014 9:34 AM, Benjamin Kaduk wrote: Hi all, There may be some interested parties over here; please feel free to chime in on this WGLC over on the kitten list. -Ben -- Forwarded message -- D

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt

ext question is ordering, will any frameworks or proxies re-order headers of the same name?  If so then we probably have to produce a sorted list of headers.   Do we need to handle repeated parameter values explicitly?   -bill On Monday, December 22, 2014 8:26 AM, "Richer, Justin P." wrot

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-00.txt

Did this get adopted as a WG item already and I missed it? On Monday, December 22, 2014 4:33 AM, Justin Richer wrote: That's easy: any headers. That's why the signer specifies which ones. Would be good to have since guidance tough, and examples.  -- Justin / Sent from my phone / -

Re: [OAUTH-WG] SPOP: Code Challenge Discussion

Quoting from 7.1  "It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence." So the spec is already recommending 256 bits of randomness, is that language not clear enough? On Wednesday, December 3, 2014 3:17 AM, Hannes Tschofenig wrot

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

ke the wording on that section stronger, I'd appreciate it.  -- Justin On Dec 2, 2014, at 2:25 PM, Bill Mills wrote: If introspection returns any other user data beyond what is strictly required to validate the token based solely on possession of the public part it would be a mistake. O

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

s all going over TLS anyway (RS->AS) just like the original token fetch by the client (C->AS). Doesn't mean you need TLS *into* the RS (C->RS) with a good PoP token.  Can you explain how this is related to "act on behalf of"? I don't see any connection.  -- Justin On Dec

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

that's associated with it and the request. What I'm saying is that you introspect the identifier and get back something that lets you, the RS, check the signature.  -- Justin On Dec 2, 2014, at 1:40 PM, Bill Mills wrote: "However, I think it's very clear how PoP tokens would w

Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01

wise I can as an attacker take that toklen and get info about it that might be useful, and I don't think that's what we want. -bill On Tuesday, December 2, 2014 6:06 AM, Justin Richer wrote: Hannes, thanks for the review. Comments inline. On 12/2/2014 6:23 AM, Hannes

Re: [OAUTH-WG] OAuth in the news again....

hopefully would emerge with a better model but that only helps the future and not now.  Do you have some suggestions to help the situation in the mean time?  On Tue Dec 02 2014 at 9:51:39 Bill Mills wrote: Mis-stated perhaps, but it's highlighting a core problem we punt on at the protocol layer

Re: [OAUTH-WG] OAuth in the news again....

Mis-stated perhaps, but it's highlighting a core problem we punt on at the protocol layer.  FB as the example here tries to make teh friction of using a FB login as low as possible, and so the user consent stuff is dialed down to the very minimum of acceptable.  This is the common pattern, get a

Re: [OAUTH-WG] OAuth in the news again....

that link does not contain the quoted text.  Also the quoted text isn't wrong when you look at the FB OAuth usage and how users actually use it. On Monday, December 1, 2014 8:42 AM, Kathleen Moriarty wrote: Hi Hannes, When something is written up and agreed upon, I'd recommend that

Re: [OAUTH-WG] draft-ietf-oauth-spop-04: a way of making code_challenge

a random 256bit value. >> >> John B. >> >>> On Nov 16, 2014, at 11:06 PM, Nat Sakimura >> <mailto:sakim...@gmail.com>> wrote: >>> >>> I am actually not convinced. Since the code verifier is 256bit random, >>> adding salt does

  1   2   >