>
>> 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.
>>
gt;
> 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:* Phil Hunt (IDM) [mailto:phil.h...@oracle.com
> ]
> *Sent:* Frid
> From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
> Sent: Friday, February 19, 2016 1:58 PM
> To: Nat Sakimura
> Cc: Mike Jones; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>
> No. Much simpler.
>
> A service p
and delete this e-mail.
From: Phil Hunt (IDM) [mailto:phil.h...@oracle.com]
Sent: Friday, February 19, 2016 1:58 PM
To: Nat Sakimura
Cc: Mike Jones; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
No. Much simpler.
A service provider has decid
: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt (IDM)
> Sent: Friday, February 19, 2016 2:09 AM
> To: Mike Jones
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>
> How does the client request the oauth configuration as
-- Mike
From: John Bradley [mailto:ve7...@ve7jtb.com]
Sent: Thursday, February 18, 2016 7:41 AM
To: Phil Hunt mailto:phil.h...@oracle.com> >
Cc: Mike Jones mailto:michael.jo...@microsoft.com> >; oauth@ietf.org <mailto:oauth@ietf.org>
Subject: Re: [OAUTH-W
.
-- Mike
From: William Denniss [mailto:wdenn...@google.com]
Sent: Thursday, February 18, 2016 11:28 AM
To: Mike Jones
Cc: John Bradley ; Anthony Nadalin ;
oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
Two review comments:
1
Phil Hunt ; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
We are establishing a registry. Some folks do use dynamic client registration.
We can register it in this document or take it out and let others register it
once the registry is established.
addressed.
>
> -Original Message-
> From: Mike Jones
> Sent: Thursday, February 18, 2016 10:18 AM
> To: Anthony Nadalin ; Hannes Tschofenig
> ; Phil Hunt ; John Bradley
>
> Cc: oauth@ietf.org
> Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its ess
y that have not been addressed.
-Original Message-
From: Mike Jones
Sent: Thursday, February 18, 2016 10:18 AM
To: Anthony Nadalin ; Hannes Tschofenig
; Phil Hunt ; John Bradley
Cc: oauth@ietf.org
Subject: RE: [OAUTH-WG] OAuth Discovery spec pared down to its essence
It's the OAuth-
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Anthony Nadalin
Sent: Thursday, February 18, 2016 10:13 AM
To: Hannes Tschofenig ; Phil Hunt
; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
I also t
, February 18, 2016 6:47 AM
To: Phil Hunt ; John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
On 02/18/2016 03:06 PM, Phil Hunt wrote:
> BTW. I think we are FAR from Last Call on this topic.
Thanks for your feedback, Phil. As you have seen I
OAuth
>> Discovery document since it isn’t always applicable.
>>
>> Cheers,
>> -- Mike
>> <>
>> From: John Bradley [mailto:ve7...@ve7jtb.com <
-WG] OAuth Discovery spec pared down to its essence
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
>
> From: John Bradley [mailto:ve7...@ve7jtb.com]
> Sent: Thursday, February 18, 2016 7:41 AM
> To: Phil Hunt
> Cc: Mike Jones ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
>
> I suspect that the configuration well-knowns a
; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
I suspect that the configuration well-knowns are going to be on the root
domain. You could try and get a user to put in
crm.example.com<http://crm.example.com>, but I suspect that is not going to
work.
I suspect that the configuration well-knowns are going to be on the root
domain. You could try and get a user to put in crm.example.com, but I suspect
that is not going to work.
If the app doesn’t have a specific protocol identifier then it would use the
default.
I don’t know if you can ge
resource service X could be any http accessible service:
* CRM
* Finance
* Payroll
* ERP
* any application on the web.
The spec seems to suggest that we use /.well-known/crm to discover OAuth config
for crm. But that may cause conflict if crm has its own discovery. Which leads
us down the path
On 02/18/2016 03:06 PM, Phil Hunt wrote:
> BTW. I think we are FAR from Last Call on this topic.
Thanks for your feedback, Phil. As you have seen I had issued a WGLC
prior to your message based on the claim from the authors that they
believe the document is finished.
We will, of course, take al
Hi Phil,
>From the RESTful perspective, it is the resource that should specify where
the client should find the configuration etc. through RFC5988.
As RFC5785 states, /.well-known/ uri is a last resort when this approach
does not work, e.g., when you cannot access the resource before knowing the
m
Can you clarify what you mean by “resource service x”?
Is that the RS base URI for the resource, a specific URI that the client is
requesting?
That is getting UMA ish.
The concept of a base RS URI is a rat hole that I prefer not to go down, as it
is something everyone thinks exists but like
Maybe SCIM was a bad example. It functions as a RESTful resource in the
context of OAuth.
I find the use of OIDC to be confusing as an example (and the default) because
it is both an OAuth resource and a security service. It is a modification of
OAuth.
Start thinking about every application
Diffrent protocols like Connect and SCIM may have different configurations,
endpoints , keys , authentication methods, scopes etc.
It should be posable to have them as one document, but forcing them to use one
document is going to cause a explosion of claim registration for discovery.
I think i
I still find the following text objectionable and confusing…
By default, for historical reasons, unless an application-specific
well-known URI path suffix is registered and used for an application,
the client for that application SHOULD use the well-known URI path
suffix "openid-configu
In response to working group input, this version of the OAuth Discovery
specification has been pared down to its essence - leaving only the features
that are already widely deployed. Specifically, all that remains is the
definition of the authorization server discovery metadata document and the
25 matches
Mail list logo
