<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 12/10/15 7:26 AM, Marvin Addison
wrote:<br>
</div>
<blockquote
cite="mid:CACOs9MR3UobRCapUoT+q1HzfjtTdvVXNN-Qa4L=A3jWhsXrHAQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote"><br>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">And I had a good chunk
of the specific endpoint indexing plugin impl done also,
that does the indexing by sub-path segments for partial
path matching like is discussed in IDP-701.</div>
</blockquote>
<div><br>
</div>
<div>Partial matching would definitely provide a needed
feature. I had convinced myself that filtering by role and
protocol was needed as well to prevent collisions between
SAML and CAS protocol entries.</div>
</div>
</div>
</blockquote>
<br>
It was already planned to include the role type QName as part of the
index key, and I floated the question in OSJ-129 whether it should
also include protocol. Thinking about it more now, perhaps it
should, for the reasons you state. <br>
<br>
I hadn't really given it much thought, but I guess the expectation
here is that in the metadata the CAS endpoints would be in a
separate SPSSODescriptor from say the SAML ones, partially because
of the protocol scoping issue? <br>
<br>
I only ask because we typically *don't* do that for SAML, v1 vs v2
vs the legacy "Shibboleth" protocol - those are usually all in the
same SPSSODescriptor. There, the endpoint Binding URI serves
(practically) to distinguish SAML 1 from SAML 2, etc. The same
would be true of CAS, I guess.<br>
<br>
But now I'm thinking we should consider the Binding to be part of
the index, either instead of or in addition to the containing
RoleDescriptor protocol. Needs more thought.<br>
<br>
<blockquote
cite="mid:CACOs9MR3UobRCapUoT+q1HzfjtTdvVXNN-Qa4L=A3jWhsXrHAQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I think mostly what
remained was deciding on what the endpoint index input
criteria would look like - reuse existing multiple
critieria or create a new compound Criterion holding data
for just this case.</div>
</blockquote>
<div><br>
</div>
<div>I think I'd need to know some of the new use cases to
make a comment. I like the idea of reusing what we have, but
that's more of a design philosophy than a practical
recommendation.</div>
</div>
</div>
</blockquote>
<br>
I was leaning towards re-use of existing also. Just needed to work
out whether we already had everything we needed. We might need to
add some new granular Criterion(s) in any case.<br>
<br>
<blockquote
cite="mid:CACOs9MR3UobRCapUoT+q1HzfjtTdvVXNN-Qa4L=A3jWhsXrHAQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Only reason why I
pulled it was: We weren't going to actually use it in
3.2.0 (for neither your CAS stuff nor inbound SAML
artifact binding). I didn't want to unnecessarily and
prematurely commit to the APIs, without having a chance to
really test them out "for real".<br>
</div>
</blockquote>
<div><br>
</div>
<div>Well, I need _something_ for IDP-701, so I expect that
would exercise the APIs if nothing else.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
Absolutely. Both the CAS stuff and SAML artifact are the initial
drivers here, so I was just waiting til we release one or both of
those to publicly commit the framework, in part so that those drive
real testing beforehand.<br>
<br>
<br>
</body>
</html>