+1
Phil
> On Dec 17, 2015, at 15:00, tors...@lodderstedt.net wrote:
>
> Hi all,
>
> the report is correct. Please consider it an errata to RFC 6819.
>
> kind regards,
> Torsten.
>
> Am 08.12.2015 16:05, schrieb RFC Errata System:
>> The following errata report has been held for document updat
I am in agreement with Brian.
I understand what Mike is trying to do is safer, but I too am concerned that
the escalation in knowledge/skills for oauth clients is significant.
This may not be the same concern as for OIDC where we can expect more
sophistication.
Phil
> On Jan 12, 2016, at 2
Hannes
I would like to propose a brief presentation on "events". While this might not
end up being oauth wg activity, I think a lot of attendees may be interested.
We might make this one of those if we have time topics.
Phil
> On Jan 15, 2016, at 12:15, Hannes Tschofenig
> wrote:
>
> Hi B
+1.
Phil
> On Jan 17, 2016, at 22:08, Anthony Nadalin wrote:
>
> I’m afraid that I would have to agree with Brian (hopefully this is not a
> trend)
>
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
> Sent: Friday, January 15, 2016 9:16 AM
> To: Hannes Tschofenig
>
+1 for adoption
+1 for Brian's comments
Phil
> On Jan 20, 2016, at 14:42, Brian Campbell wrote:
>
> I conditionally accept this document as a starting point for work in the
> OAuth working group on the assumption that the considerable simplifications
> discussed and accepted at
> http://www
Right but OAuth is the layer that needs to relay the request to the authen
service.
+1 on adoption
However we need to discuss more on w this as a registry or how it is used in
the overall architecture to pass signalling (hint maybe that falls to connect?)
Phil
> On Jan 20, 2016, at 12:37, J
I recall making this point in Germany. 99% of existing use is fine. OIDC is
probably the largest community that *might* have an issue.
I recall proposing a new security document that covers oauth security for
dynamic scenarios. "Dynamic" being broadly defined to mean:
* clients who have configu
e with the very first assumption. The user-agent sets
>>>>> up a non TLS protected connection to the RP? That’s a fundamental
>>>>> violation of 6749.
>>>>>
>>>>> Also, the second statement says the RP (assuming it acts as OAuth clien
Also the authz endpoint is required to force tls. So if the client doesn't do
it the authz should reject (eg by upgrading to tls).
Phil
> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) wrote:
>
> When the RP acting as the client issues a authorize redirect to the UA it has
> to
ll
> not TLS-protected, and modified on the attacker’s proxy.
>
> Section 3.2 of this report also describes the same flow.
> http://arxiv.org/pdf/1601.01229v2.pdf
>
>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) wrote:
>>
>> Also the authz endpoint is required to f
Agreed.
The security ext draft might fit well with the general grab bag of issues
around all the "dynamic" cases.
It would be stronger than a new threat model ext draft which would likely be
informational.
Phil
> On Jan 26, 2016, at 12:10, Torsten Lodderstedt
> wrote:
>
> Hi Mike,
>
>
We discussed that redirecr helps but we wanted the Token endpoint to also be
able to detect assuming many client devs won't implement the check.
Phil
> On Jan 28, 2016, at 20:54, Nat Sakimura wrote:
>
> My preferred way of dealing with mix-up has been to use separate redirection
> URI but yo
There is a more general problem in PaaS deployment about how RA and AS
infrastructure discover and coordinate with each other. For the most part this
hasn't been necessary since usually the AS and RS are controlled by the same
admins. But in PaaS/IaaS the requirements vary widely.
How does an
Another example is to look at scim discovery(in contrast with connect).
When asked separately the answers may be different.
Asking what is the oauth server for scim is yet another relation. So may be we
need a scheme for oauth where query is rs:someval and optionally an acnt value
to.
For e
ount
> identity may mean 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) wrote:
>>
>> Another example is to look at scim discovery(in contrast with connect).
&g
Thanks Mike.
Phil
> On Feb 11, 2016, at 22:07, Mike Jones wrote:
>
> Draft -05 incorporates the feedback described below - deleting the request
> parameter, noting that this spec isn't an encouragement to use OAuth 2.0 for
> authentication without employing appropriate extensions, and no lon
Yes
Phil
> On Feb 13, 2016, at 07:59, "tors...@lodderstedt.net"
> wrote:
>
> So basically, the RFC could also just establish the new registry and oidf
> could feel in the values?
>
> (just trying to understand)
>
>
>
> Originalnachricht
> Betreff: RE: [OAUTH-WG] Authenti
>>>>
>>>> I don't see any harm in the spec that establishes the registry also
>>>> seeding it with all known values in use at the time of drafting,
>>>> regardless of the group that originally specified them. Makes the original
>>>> s
s also my preference to register the current values.
>>>>>
>>>>> I don't see any harm in the spec that establishes the registry also
>>>>> seeding it with all known values in use at the time of drafting,
>>>>> regardless of the g
How does the client request the oauth configuration assigned to xyz?
The example you give appears to presume a single oauth infrastructure for all
apps.
The only way right now to have apps specific oauth is to infer the relation by
the domain "xyz.example.com".
That makes discovery more com
let me know. If it is not, please
> correct me.
>
> Cheers,
>
> Nat
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender and delete this e-mail.
>
> From
ot be a problem in reality but it needs to work.
>
> Is this correct?
>
> Nat
>
> --
> PLEASE READ :This e-mail is confidential and intended for the
> named recipient only. If you are not an intended recipient,
> please notify the sender and delete this e-mail.
>
Option A
Phil
> On Feb 19, 2016, at 13:39, Hans Zandbelt wrote:
>
> Option A: I agree with Mike that the complexity and implementation cost of
> Option B will make adoption harder, which was also a concern with the first
> iteration of Option A.
>
> To be honest, I'm not sure most people wou
I am suggesting that part of the discovery solution has to be the client
indicating what resource endpoint it wants the oauth configuration data for.
So if res.example.evil.com is not a valid resource endpoint for as.example.com
the authz discovery should fail in some way (eg return nothing).
a standard format. “Security by obscurity” adds no
> real security at all.
>
> -- Mike
>
> From: Anthony Nadalin
> Sent: Wednesday, February 24, 2016 10:01 AM
> To: Mike Jones ; Phil Hunt (IDM)
> ; Nat Sakimu
;
> Is there a reason that you would like the syntax for any of these or the
> other generally applicable OAuth 2.0 metadata values to be different? I
> don’t see any good reason for unnecessary differences to be introduced.
>
>
ng actively discussed by the working group. For instance, see
> George Fletcher’s recent contribution.
>
> Thanks for the good discussion, Phil.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
plicable.
>
> But first, we need to finish the existing spec, so that the registry enabling
> these extensions gets established in the first place.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:phil.h...@oracl
register those that are of general applicability.
>
> -- Mike
>
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
> Sent: Wednesday, February 24, 2016 3:52 PM
> To: Mike Jones
> Cc:
> Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery
The issue for any service is that things like gateways and proxies may change
or add parameters.
There is a long tradition with http to mess with things headers and payload in
the real world. Not ideal, but a certain reality.
Thus for certain services it is likely only possible to sign a subse
+1 for adoption. Again.
Phil
> On Mar 2, 2016, at 17:03, William Denniss wrote:
>
> I support adoption of this specification by the working group.
>
> We are already using some values in production and I see interoperability
> advantages in having these standardized.
>
>> On Wed, Mar 2, 20
I strongly oppose. 2 major issues.
This is not service discovery this is configuration lookup. The client must
have already discovered the oauth issuer uri and the resource uri.
The objective was to provide a method to ensure the client has a valid set of
endpoints to prevent mitm of endpoint
ition:
>
> 12. A way to express a list of valid RSs for this AS needs to be added to
> section 2.
>
> Best,
>
> Nat
>
> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) :
>> I strongly oppose. 2 major issues.
>>
>> This is not service discovery this
; Lets keep the two issues separate.
>
> John B.
>
>
>
>
>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin wrote:
>>
>> The relationship between AS and RS need to be scoped to “does this RS accept
>> tokens from this AS” as a list is too much information t
rization Server Metadata"
> should keep it's scope to the publishing of authorization server metadata.
> The act of doing discovery is beyond its scope and so is trying to prevent a
> client from presenting a token to someplace it shouldn't.
>
>
> On Fri, Mar 11
A header might open another attack vector. Better to parse the jwt and look for
the issuer assuming the jwt validates.
Phil
> On Mar 12, 2016, at 09:02, Jim Willeke wrote:
>
> Why not register JWT as an access token type and then the the Issuer is
> implied?
>
> --
> -jim
> Jim Willeke
>
>
016, at 11:29, Jim Willeke wrote:
>
> Would a header be a concern if TLS was used for transportation?
>
> --
> -jim
> Jim Willeke
>
>> On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM)
>> wrote:
>> A header might open another attack vector. Better to
Inline
Phil
> On Mar 14, 2016, at 14:13, John Bradley wrote:
>
> We had two mandates. One was to provide a spec for AS metadata. The other
> was to mitigate the client mixup attack. The request was to do the latter
> without requiring the former for clients that don’t otherwise need disco
urrent token
>>>>> exchange document. We should be consistent across drafts in that regard.
>>>>> The second is more traditional scope-ish. The third has been patched in
>>>>> with things like “offline_access” in certain APIs.
>>>>>
&
There are two variations.
Mitm the token endpoint is different then working one legit token endpoint
against another thru redirect and state misdirection.
In the mitm version you don't need multiple AS's.
Phil
> On Mar 18, 2016, at 15:04, Brian Campbell wrote:
>
> The "a. wrong AS /token e
gt;>>>> client spoofing.
>>>>>>>>>>> William and I are working on that in the mobile best practices
>>>>>>>>>>> draft.
>>>>>>>>>>>
>>>>>>>>>>> J
working on that in the mobile best practices
>>>>>>>>>>> draft.
>>>>>>>>>>>
>>>>>>>>>>> John B.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>&
uest validation of the issuer and
> client_id returned by the Authorization endpoint.
>
> My proposal is to have the client send the RS URI to the AS and let it check
> with each request as well and skip the requirement for discovery.
>
> Your proposal doesn’t remove the
George
Very good question...
I considered that the RS metadata discovery could be fake.
So the final step in configuration validation is to bind the relationship
between as and rs discovery together to confirm the relationship is valid.
We are of course assuming that a hacker needs to use th
Sounds good.
Phil
> On Mar 21, 2016, at 15:18, Hannes Tschofenig
> wrote:
>
> Hi Phil,
>
> we can put this topic as an additional agenda item to the list by
> removing time from the PoP and the mix-up agenda items
>
> Ciao
> Hannes
>
>> On 03/21/2016 09:46 PM, Phil Hunt wrote:
>> I’m not s
Is the idp the center of all things for these users?
Usually you have a provisioning system that coordinates state and uses things
like scim connectors to do this.
Another approach from today would be to pass a scim event to the remote
provider which then decides what needs to be done to facil
> is a bunch of cutting and pasting of access tokens / keys / certs and doing a
> bunch of config that is error prone and unique for each relationship.
>
> Don’t want to solve on the thread … looking to see if there is interest!
>
> On 4/5/16, 7:11 PM, someone claiming to b
I would like to have more discussion before wg adoption.
I support the work and am willing to help.
Phil
> On Apr 6, 2016, at 14:25, 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-cam
Existing implementations are for the large part ok and do not need these
mitigations.
Only the new use cases we have been discussing (configure on the fly and
multi-as, etc) really need mitigation.
The updated by approach seems like a good way to address the new cases.
Phil
> On Apr 6,
er you want to discuss it.
>
> Ciao
> Hannes
>
>
>> On 04/06/2016 08:07 PM, Phil Hunt (IDM) wrote:
>> I would like to have more discussion before wg adoption.
>>
>> I support the work and am willing to help.
>>
>> Phil
>>
>>> O
utilize OAuth.
>>>
>>> I think time is right to define scopes more precisely. As the discussions
>>> in the last days proved again (at least for me), scope is not sufficiently
>>> defined to come up with interoperable implementations. Additionally, there
>
I am finding I am not happy with solving the bad resource endpoint config issue
with resource indicator. At best I see this as a special use draft for things
like collab services or things which aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that config
ming from. The pattern described in the draft
> (using a different parameter name but otherwise the same) is deployed and
> in-use for normal OAuth cases including and especially the resource owner
> centric ones.
>
>
>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
&g
John's assertion that RI can be used to detect mis-configured clients would
make it mandatory.
To avoid that we need a config time solution for misconfiguration.
Phil
> On Apr 12, 2016, at 01:30, Sergey Beryozkin wrote:
>
> Hi
>> On 11/04/16 23:19, Phil Hunt (IDM) wrot
rity goal of
> token binding.
>
> John B.
>
>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin wrote:
>>
>> Hi
>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote:
>>> I am objecting to modifying the protocol in the default case as a
>>> majority
To be clear what I am saying... RI should be considered on its own merits as an
optional protocol extension.
I do not believe it has merit when linking it to client mis-configuration
detection. The issues should be kept separate.
Phil
> On Apr 12, 2016, at 09:00, Phil Hunt (IDM) wr
I don't have this issue. I see your point, but I think the constrained branding
makes it clear.
IOW. When the specs say "constrained web" 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
This is off topic for the errata process. This is not the place to propose a
re-write.
As one of the authors of the threat model and sec considerations I think we
covered this to too much. :-) Justin's comments are spot on.
This has nothing to do with user authentication.
Phil
> On Jul 28,
You might be munging two different flows with different semantics together.
First flow is use oidc to authen the user to the client.
Second flow is normal oauth authorization to get an at to access the resource.
Often the OP AS is different from the RS's AS and the rs needs a proper
"delegat
This is as bad as assuming an access token means someone was authenticated.
In this case the audience of the id token is not the resource and other badness
may ensue.
Phil
> On Aug 4, 2016, at 8:17 AM, Sergey Beryozkin wrote:
>
> Hi Phil
>
>> On 04/08/16 15:01, Phi
I am aware of no IPR.
Phil
> On Sep 19, 2016, at 2:26 AM, Mike Jones wrote:
>
> I am aware of no IPR on this specification.
>
>-- Mike
>
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, September 19, 201
While the tokbind seems strategic, there are concerns about universality. A
chief barrier is getting all tls termination points to support - a matter of
substantial time.
There are also those that argue that we still need an app layer end-to-end
solution that pop provides.
That said, I am no
Maybe if we reworked the signing doc so content types like xml and json could
be signed?
This would cover for the majority of web api cases.
Wonder what the advice of the http wg would be on this.
Phil
> On Oct 24, 2016, at 8:29 AM, Samuel Erdtman wrote:
>
> +1 on doing PoP work in this
+1
Phil
> On Nov 4, 2016, at 6:11 PM, John Bradley wrote:
>
> I can easily see Research and education publishing self signed certs in
> meta-data that is then used for client authentication and other things.
> I don’t want to limit this to only CA issued certs where the client_id is in
> the
John's comments
Phil
> On Nov 7, 2016, at 8:43 AM, Samuel Erdtman wrote:
>
> Phil, what is your +1 referring to?
>
> //Samuel
>
>> On Sat, Nov 5, 2016 at 2:14 AM, Phil Hunt (IDM) wrote:
>> +1
>>
>> Phil
>>
>>> On Nov 4, 20
For example scim has many resources. But it is reasonable to discover at its
root since clients may ask for other resources. The as would not likely change
across a single scim provider.
Phil
> On Nov 13, 2016, at 5:27 PM, Torsten Lodderstedt
> wrote:
>
> I see your point but do you really
+1 to AppAuth
One disturbing pattern I see for mobile apps relaying the idtoken is that the
aud isn't checked by the AS in the Oauth exchange. This in part caused by the
fact that the mobile app has two client-id identifiers. If the aud only has the
clientid for the OIDC call this can be a prob
Afaik, the client app ends up with an access token (at). It never has to deal
with id tokens. That all happens by way of the oauth AS server calling oidc
itself. Iow the oauth as is the oidc client.
The code in the mobile client is trivial by comparison and does not need to do
id token valid
An seeing bad impls with justins pattern. In particular aud is not checked.
The idp has to know the rsrc aud or the as has to know the client id the mobile
app is using with OP provider. It ends up being complex with room for mistakes.
Phil
> On Jan 26, 2017, at 10:00 AM, John Bradley wrote:
What is concerning is that many are using resource owner flow so the client app
can capture the uid/password under the assumption that the client needs to
control the branding experience much has been done in silo approaches of the
past.
Adding to the confusion I note that many of the cloud pr
You are headed down the road to a very big domain called identity management
and provisioning.
You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.
SCIM is usually OAuth enabled but the scopes/rights have not yet been
standardized. There is however some obvious access cont
+1 for adoption
Phil
> On Apr 20, 2017, at 10:40 AM, John Bradley wrote:
>
> I accept the adoption as a starting point.
>
> John B.
>
>> On Apr 20, 2017, at 1:32 PM, Hannes Tschofenig
>> wrote:
>>
>> Hi all,
>>
>> based on the strong support for this document at the Chicago IETF
>> meeti
This is why i expect a secevent token revocation event to be defined to
complement 7009 once secevents moves further along.
We want to be able to know in near real time when a token is revoked to avoid
constant checks to see if a token is still good.
Phil
> On Jun 6, 2017, at 3:18 PM, Justin
Thank you Mike!
Phil
> On Jun 16, 2017, at 5:50 PM, Mike Jones wrote:
>
> The Authentication Method Reference Values specification is now RFC 8176.
> The abstract describes the specification as:
>
> The amr (Authentication Methods References) claim is defined and registered
> in the IANA "
+1
Thanks Mike.
Phil
> On Jul 4, 2017, at 12:43 PM, Mike Jones wrote:
>
> The JWT BCP draft has been updated to describe the use of explicit typing of
> JWTs as one of the ways to prevent confusion among different kinds of JWTs.
> This is accomplished by including an explicit type for the
+1 adoption
Phil
> On Jul 20, 2017, at 11:26 AM, John Bradley wrote:
>
> I support adoption
>
>> On Jul 20, 2017, at 2:37 PM, Rifaat Shekh-Yusef
>> wrote:
>>
>> All,
>>
>> We would like to get a confirmation on the mailing list for the adoption of
>> the JSON Web Token Best Current Practi
In OAuth, the audience for the token is the resource server and not the client.
OAuth delegates a client to act for a user. OIDC issues an ID token whose
audience is the client.
Assuming OAuth...
The life of the token is dependent on the risk at the resource.
Refresh token lets the client do
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.
>
> Seems to me that refresh token has the same possible security risks in
> an Angular app as
78 matches
Mail list logo
