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

Justin Richer jricher at mit.edu
Fri Aug 12 11:29:58 UTC 2016


Thanks, both this point and the one about the OIDC provider tell me that 
perhaps the list ought to reference both official and common names, 
since people do talk about resource servers and identity providers as 
well. That's easy enough to put up front, as long as we pick only one 
term to use throughout the document itself.

  -- Justin


On 8/11/2016 8:00 PM, Mike Jones wrote:
> 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