[Openid-specs-heart] Formal component definitions and compliance

Mike Jones Michael.Jones at microsoft.com
Fri Aug 12 00:00:07 UTC 2016


As I was working on https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00, I had to sort out the difference between "protected resource" and "resource server".  As with many thing, RFC 6749 could have been clearer on this point, but if you look at the usage of the terms in 6749, "protected resource" is the endpoint you interact with and "resource server" is a nebulous concept of a server that implements one or more protected resources.  I agree that "protected resource" is the right term for this list.

				-- Mike

-----Original Message-----
From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Salyards, Kenneth (SAMHSA/OPPI)
Sent: Thursday, August 11, 2016 5:10 PM
To: Justin Richer <jricher at MIT.EDU>; openid-specs-heart at lists.openid.net
Subject: Re: [Openid-specs-heart] Formal component definitions and compliance

I think this is a great idea. So, is a protected resource a resource server? Thanks, Ken

-----Original Message-----
From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Justin Richer
Sent: Thursday, August 11, 2016 4:21 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Formal component definitions and compliance

This week, I’ve been working on some text updates to the mechanical specifications, and I’ve come up with something I’d like to run by the group. 

Specifically, our specs profile eight different components, and I’ve now formally listed them out in the specs themselves:

 - OAuth 2.0 client
 - OAuth 2.0 protected resource
 - OAuth 2.0 authorization server
 - OpenID Connect 1.0 relying party
 - OpenID Connect 1.0 identity provider
 - UMA 1.0 client
 - UMA 1.0 protected resource
 - UMA 1.0 authorization server

And of course, the interactions between all of these components are really what the protocol’s about. It’s looking useful to have this spelled out in the new “compliance” section up front, but what wondering is whether we should try to instrument or tag the rest of the document to indicate which component interactions are affected by each major requirement. 

Furthermore, this might lead to a more sensible division of the document text by functional pairings. As in, all of the features of the AS that are needed to talk to the RS would end up in one section, separate from the bits that the AS needs to talk to the client. That level of rewrite is would take some effort, but if we managed to line up all our requirements like this it might be worth it.

I’d like thoughts on either of these approaches, and you can see the provisional language in the source .xml files in the repository as of this afternoon.

Thanks,
 — Justin
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart
_______________________________________________
Openid-specs-heart mailing list
Openid-specs-heart at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-heart


More information about the Openid-specs-heart mailing list