I am not aware of any IPR associated with this specification.
Phil
phil.h...@independentid.com
> On Jul 10, 2024, at 9:06 AM, Rifaat Shekh-Yusef
> wrote:
>
> Mike, Phil, Aaron,
>
> As part of the shepherd write-up, all authors of the OAuth 2.0 Protected
> Resource Metadata draft must c
+1. I agree this is ready. PhilOn May 17, 2024, at 1:35 PM, Giuseppe De Marco wrote:+1 for publicationIl giorno mer 15 mag 2024 alle ore 16:11 Rifaat Shekh-Yusef ha scritto:All,This is a second WG Last Call for the OAuth 2.0 Protected Resource Metadata document (the prev
Agreed. Most of dyn reg cases we were thinking about occurred because there was
a need to register each copy of the same client software. The software
statement was intended to allow the registration endpoint recognize software
and to fix things like endpoints.
Automatic registration of single
Justin
Thanks for this. I am pleased the HTTPbis group took this up. It is a multi-WG
issue that needs their expertise.
I look forward to reading the new draft.
Cheers,
Phil
> On Apr 29, 2021, at 8:34 AM, Justin Richer wrote:
>
> Many of you will remember an old draft that I was the edito
One thing that this thread is overlooking (Hannes and others have mentioned
it) is that OAuth is an *authorization* protocol not intended for
authentication.
OAuth is not really for federation and sharing of claims. The idea is for an
authz server to issue short term tokens that contain enou
+1
Phil
> On Jun 22, 2020, at 3:16 PM, Mike Jones
> wrote:
>
>
> +1 from me too
>
> From: OAuth On Behalf Of Torsten Lodderstedt
> Sent: Sunday, June 21, 2020 2:42 PM
> To: Falk Andreas
> Cc: oauth
> Subject: Re: [OAUTH-WG] A proposal for OAuth WG Interim Meetings in place of
> IETF108
Denis,
I agree with Hannes. Speaking as one of the security consideration and threat
model authors for OAuth2, a foundational design assumption was always that
access tokens are opaque to clients.
Even in the case of OIDC they created the id token to be a token defined for
the client in the s
One of the use cases brought up in the ROPC thread mentioned that redirect was
hard to do in some cases (like IoT). This reminded me of RFC8628, the OAuth
Device Authorization Grant. I mention it because for *some* of the cases who
say redirection is hard may be able to use the Device Authz Gran
We are not discussing anything new here. We are discussing adoption of best
practice.
The disconnect appears to be that one dependent standard’s “typical” use
(nonces) does not have the ietf consensus as best practice.
This lack of consensus needs to be resolved.
Phil
> On May 8, 2020, at
+1
Phil
> On May 7, 2020, at 11:50 PM, Daniel Fett wrote:
>
>
> +1 to all what Aaron said. Thanks for pointing this out!
>
> We need to address this in the security BCP and this will be a normative
> change that affects OpenID Connect Core (just as our current recommendation
> on the usag
-- Mike
>
> From: Aaron Parecki
> Sent: Wednesday, May 6, 2020 12:29 PM
> To: Steinar Noem
> Cc: Phillip Hunt ; Mike Jones
> ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.1 - require PKCE?
>
> I should add that even some OpenID Connect profiles require PKCE,
#x27;t?
>
>> ons. 6. mai 2020 kl. 21:12 skrev Phillip Hunt :
>> Mike,
>>
>> The point of 2.1 is to raise the security bar.
>>
>> Yes it adds new MUST requirements.
>>
>> But what about OIDC would break other than required implementation of
Mike,
The point of 2.1 is to raise the security bar.
Yes it adds new MUST requirements.
But what about OIDC would break other than required implementation of PKCE to
support 2.1?
Eg Would additional signaling be required to facilitate interoperability and
migration between versions? Would t
I noticed this BOF on the IETF virtual conference agenda for today. It seems to
cover a lot of areas discussed in the OAuth WG and may be of interest.
https://datatracker.ietf.org/meeting/107/session/privacypass
Cheers,
Phil Hunt
@independentid
phil.h...@independentid.com
___
I do not plan to attend in person but I will be around.
Phil
> On Mar 9, 2020, at 11:48 AM, Brian Campbell
> wrote:
>
>
> I plan to be in Vancouver.
>
> But recognize there's some uncertainty about it all, which was the
> inspiration for the closing slide used in the interim just now:
Why not just require service accounts to use mutually acceptable http method of
authentication? Eg instead id/password, service acnt client could use mtls
auth or http basic or some other method.
AFAIK this is already widely done.
Is there so much interop value that specifying only the weak
It may be programmatically equiv but from a trust perspective very different.
Usually client cred flows are from trusted entities and fixed endpoints.
Phil
> On Feb 21, 2020, at 5:05 PM, Richard Backman, Annabelle
> wrote:
>
> ROPC without a client ID or authentication is functionally equi
I do recall password flow was only in 6749 to facilitate transition to oauth..
Maybe it is reasonable to consider ending it now.
Phil
> On Feb 18, 2020, at 1:15 PM, Justin Richer wrote:
>
> There is no need for a grace period. People using OAuth 2.0 can still do
> OAuth 2.0. People using OAu
-1. I think you should be suggesting alternative text at this stage. We all
have same responsibilities here.
Phil
On 2012-01-03, at 15:18, Michael Thomas wrote:
> Barry -- It's now been two weeks and I haven't heard anything to
> the objections I raised. It is not my responsibility to come up
The issue is that the service provider will likely only accept ONE token format
in practice. The security requirements of the scenario dictate choice of Mac or
bearer or for that matter any other new scheme.
An MTI would complicate the spec by implying a choice of tokens by the client
because
Agreed.
Phil
On 2011-09-16, at 12:08, Torsten Lodderstedt wrote:
> I reviewed the diffs and it looks ok.
>
> regards,
> Torsten.
>
> Am 07.09.2011 17:59, schrieb Barry Leiba:
>> As you've all probably seen, Eran has posted version 21 of the OAuth
>> base spec, in which he believes he's addre
You can also use a long lived refresh token in combination with a short access
token. The client is then forced to periodically reauthenticate (without the
user) before getting a new access token.
Refresh also gives the authzn server a chance to revoke access. Hence it is
better to use shorter
+1
Phil
On 2011-08-16, at 13:04, Peter Saint-Andre wrote:
> How's this?
>
> The authorization server MUST support Transport Layer Security
> (at the time of this writing, the latest version is specified in
> [RFC5246]). It MAY support additional transport-layer mechanisms
> meeting its
f someone publishing an I-D with a full syntax and
> canonicalization requirements for say, singing an entire request, headers and
> all. I feel that would be much better accomplished by defining a new HTTP
> authentication scheme.
>
>
>
> Philosophically, I think exten
No. I don't think so. In the new variant the client has to check the returned
state to confirm it has not changed or associated with a different user.
Previously the authz server had to do the checks.
Phil
On 2011-08-13, at 21:16, "William J. Mills" wrote:
> The defense is the same though,
Phil
On 2011-08-02, at 18:02, Eran Hammer-Lahav wrote:
> The idea is to drop 'ext' and 'bodyhash' due to being underspecified and
> therefore causing more harm than good. I added 'ext' to allow for application
> specific data to be included in the signed content. However, the name
> suggest
The notion of client instance ids (eg as suggested) by USIMs suggested may be a
slightly different identify then envisioned by client_id.
I have mentioned the same issue before of identifying software separately from
deployment instances which such a strong credential would map to.
They likel
Will take a look.
Phil
Sent from my phone.
On 2011-04-11, at 8:19, Justin Richer wrote:
> While this isn't the original use case I had in mind, this could be
> covered by something in the OAuth2 Instance extension:
>
> http://tools.ietf.org/html/draft-richer-oauth-instance-00
>
> -- Justin
Yes agreed. The way I read it any flow can omit client credential if they have
another means to identify it.
Phil
Sent from my phone.
On 2011-04-05, at 6:24, Justin Richer wrote:
> Phil,
>
> It's completely within the normative language of the spec to do things
> this way right now -- the
ar Woodward wrote:
>>>>
>>>>> But mobile clients aren't vulnerable to this type of attack because all
>>>>> of their code is contained on the device and they make all outgoing
>>>>> requests to the provider via SSL. There are no redire
It doesn't require client side ssl.
Phil
Sent from my phone.
On 2011-04-04, at 11:47, Skylar Woodward wrote:
> How does the client app transmit the nonce (random number) to the web browser
> for redirect to the provider? If the client app does not support HTTPS, it
> can't set up a secure
For the record, I can except SHOULD. But my very strong feeling is this leads
to much more lengthy and complicated language.
I believe we have already crossed the line where it is no longer easy for
deployers to figure out if deployments are secure. It is now a spec challenging
to even subject
By not feasible, what is the technical use case/issue?
Phil
Sent from my phone.
On 2011-04-01, at 21:52, Skylar Woodward wrote:
> Am I the only one still supporting SHOULD on this case? If someone else
> supports this language, please speak up. Otherwise, it seems the group SHOULD
> move f
Sorry. I forgot to add it becomes a race if and only if the TS is smart enough
to invalidate code after first use.
Phil
Sent from my phone.
On 2011-04-01, at 18:07, Skylar Woodward wrote:
> I'm going to summarize (hopefully faithfully) the attacks referenced here,
> with the hope of attemp
Why can't TLS be a must except when the token cannot be exposed. Eg because the
redirect is local?
Phil
Sent from my phone.
On 2011-03-29, at 22:48, Eran Hammer-Lahav wrote:
> Francisco – thanks for being persistent.
>
>
>
> Sounds like the same problem exists in OAuth 1.0. Basically, t
I agree with what you are saying. We were having trouble understanding legs
too, so I came up with the diagram. The diagram does show the parties aspect.
But I remain uncomfortable about the terminology.
Phil
Sent from my phone.
On 2011-03-18, at 15:55, David Primmer wrote:
> Hi Phil,
>
>
I have not seen any detailed agenda for IETF 80. If there will be votes that
override email votes all participant should so be informed.
Phil
Sent from my phone.
On 2011-03-11, at 17:46, Anthony Nadalin wrote:
>> Why the early cut-off date? As this is in advance of IETF 80, changes will
>>
Extensibility for the new option would be defined within each spec.
It doesn't seem right to put registry in bearer spec. What if one is defining a
non-bearer spec?
Phil
Sent from my phone.
On 2011-03-11, at 15:41, Mike Jones wrote:
> That would be yet a different option. With (C), the ini
Thoughts on what makes up "lightweight web services" of which OAuth2 plays a
key role.
http://independentidentity.blogspot.com/2011/03/lightweight-web-services.html
Comments welcomed.
Phil
Sent from my phone.
___
OAuth mailing list
OAuth@ietf.org
You can put in client_assertion but also leave the 'other' credential option
there as well
Phil
Sent from my phone.
On 2011-02-18, at 10:17, Hannes Tschofenig wrote:
> Hi all,
>
> I asked for feedback regarding the removal of the client assertion
> credentials earlier this month, see
>
;
> phil.h...@oracle.com
>
>
>
>
>
>
>
>
> On 2011-02-07, at 9:54 AM, Eran Hammer-Lahav wrote:
>
>
>
>
> What don’t you agree with?
>
>
>
> EHL
>
>
>
> From: Phillip Hunt [mailto:phil.h...@oracle.com]
> Sent:
-1
I don't agree fully here.
Phil
Sent from my phone.
On 2011-02-07, at 0:02, Eran Hammer-Lahav wrote:
> Yes, any token issued via OAuth by an authorization server is an OAuth token
> by definition. Which makes ‘token_type=oauth2’ an silly and confusing
> statement, given that any token i
My understanding is you can still do it. It is covered by the new other auth
mechanism paragraph.
The real question is do we need it for interop purposes or not?
We had other methods that didn't fit draft 11 either. So do u spec them all or
just one mandatory to implement?
Phil
Sent from my
The client does need to know how to authenticate. But given that it already has
to know a lot about the service, you would think acceptable authentication
types are well known to the client.
What is the problem with the client authenticating like any normal web service
client? (IE outside of o
Not sure I agree. Yes shared secret But one may be long lived (permanent)
while the other may be good for minutes. If a server has both what then? I
suppose we could detect type in client_secret or do it by policy associated
with a client_id. Is that what is intended in the spec?
As you say "
xtension mechanism for new parameters. Why is that not enough?
>
>
>
> EHL
>
>
>
> From: Phillip Hunt [mailto:phil.h...@oracle.com]
> Sent: Saturday, January 15, 2011 12:52 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Removal: Clien
A strong client credential is needed in many cases. I had assumed client
assertion would fulfill this need.
Phil
Sent from my phone.
On 2011-01-14, at 22:45, Eran Hammer-Lahav wrote:
> I would like to suggest we drop the client assertion credentials (-11 section
> 3.2) from the specificati
47 matches
Mail list logo