<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wouldn’t personally want to implement policy the level you describe, but it seems that it could technically be mapped to a SAML entity.  An entity could just describe “VT Campus Resources,” or somesuch.</blockquote><div><br></div><div>The Service Registry is the simplest solution for deployers that want to register groups of relying parties in a single stroke. I see this new facility living alongside the Service Registry.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, I guess a question is, when folks implement a policy like the above, would attribute release be implemented at the same granularity?<br></blockquote><div><br></div><div>Too many unknowns at this point to say.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The biggest sticking point that comes to mind is that the CAS service parameter is currently being passed to the Attribute Filter, which probably wouldn’t be what one would want if CAS clients were represented as first class entities.<br></blockquote><div><br></div><div>While I suppose it can be an arbitrary URI, the input into the metadata resolver MUST be the service URL. The difficulty is that CAS clients allow the service URL to vary for a single logical application [1], which leads to needing a matching engine like what&#39;s in PatternServiceRegistry now. That could be ported to a metadata resolver, of course, but it&#39;s a complexity peculiar to the CAS protocol that produces some impedance mismatch with SAML metadata IMO.</div><div><br></div><div>M</div><div><br></div><div>[1] It&#39;s possible to configure a static service URL in most CAS clients, but I would say that configuration is the less common one.</div><div><br></div></div></div>