Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

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 <torsten@lodderstedt.net> wrote:
> 
> I see your point but do you really think this is needed and efficient enough for practical use?
> 
> Basing metadata handling on single resources (distinct URLs including different query parameters, right?) in my opinion means:
> - the client needs to discovery the AS for every of those URLs
> - the client needs to acquire an access token per URL
> - I'm not quite sure what it means when it comes to token binding
> 
> I think it would be good idea to have a container on a more coarse grain level in order to make that more efficient. If every resource (distinct URL) belongs to such a container (let's call it resource server or something else), the client-side handling should become     easier.
> 
> BTW: we don't have different meta data for token endpoint and authorization endpoint of a particular AS, right? So the comparision does not completely fit.
> 
> What do you think?
> 
> best regards,
> Torsten.
> 
> 
> 
>> Am 13.11.2016 um 15:37 schrieb Mike Jones:
>> Actually, it’s intentionally a particular resource that the metadata applies to – exactly as the AS metadata applies to a particular AS.  It is *not* metadata about all resources that might be managed by a resource server, just as the AS metadata is not about all ASs that a particular server (such as a multi-tenant server) might manage.
>>  
>> Bear in mind that just as different ASs are likely to use different keys for security reasons, even if they are on the same physical server – such as in the multi-tenant case, different resources need to be able to use different keys, even if they are hosted at the same resource server.  That mandates the metadata being resource-specific.
>>  
>> For what it’s worth, if we ever do an OAuth 3.0, I believe we should get rid of the “resource server” term entirely.  It doesn’t have any actionable semantics tied to it and its existence only encourages confusion.
>>  
>> Thanks for reading the draft, Torsten.
>>  
>>                                                        -- Mike
>>  
>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] 
>> Sent: Sunday, November 13, 2016 2:32 PM
>> To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
>> Cc: gffletch@aol.com
>> Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00
>>  
>> Hi Mike,
>> 
>> just read your spec and I'm also a bit confused about the "resource" meta data element in section 2.
>> 
>> I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective element "resource_server". In the example George gave the URL would be "https://idp.example.com/tenant/<tenantid>/". Resource managed by a particular resource server could use sub-paths of the respective URL, such as " https://idp.example.com/tenant/<tenantid>/users/<userid>".
>> 
>> best regards,
>> Torsten.
>> 
>> Am 05.08.2016 um 02:10 schrieb George Fletcher:
>> Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00.
>> 
>> 1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging".
>> 
>> 2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API.
>> Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of...
>> 
>>     CREATE -- POST https://idp.example.com/tenant/<tenantid>/users
>>     READ -- GET https://idp.example.com/tenant/<tenantid>/users/<userid>
>>     UPDATE -- PUT https://idp.example.com/tenant/<tenantid>/users/<userid>
>>     DELETE -- DELETE https://idp.example.com/tenant/<tenantid>/users/<userid>
>> 
>> Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added?
>> 
>>    ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource
>> 
>> In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior?
>> Thanks,
>> George
>> 
>> 
>> 
>> _______________________________________________
>> 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