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

[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 --
PUThttps://idp.example.com/tenant/<tenantid>/users/<userid>
DELETE --
DELETEhttps://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

[Torsten Lodderstedt]

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.

Post by 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 --
PUThttps://idp.example.com/tenant/<tenantid>/users/<userid>
DELETE --
DELETEhttps://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
https://www.ietf.org/mailman/listinfo/oauth

[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:***@lodderstedt.net]
Sent: Sunday, November 13, 2016 2:32 PM
To: Mike Jones <***@microsoft.com>; ***@ietf.org
Cc: ***@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

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/oauth

[Torsten Lodderstedt]

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.

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
*Sent:* Sunday, November 13, 2016 2:32 PM
*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.
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
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt (IDM)]

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

I see your point but do you really think this is needed and efficient enough for practical use?
- 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.

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
Sent: Sunday, November 13, 2016 2:32 PM
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.
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
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth