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 <[email protected]> > 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:[email protected]] >> Sent: Sunday, November 13, 2016 2:32 PM >> To: Mike Jones <[email protected]>; [email protected] >> Cc: [email protected] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
