Minutes: focus group call Tue 24-Feb-2004

[Jeff Hodges <Jeff.Hodges@Sun.COM>]

send comments to the list if there're bugs herein or missing items. thanks.

============================================================================
focus call notes Tue 2/24/2004 9:04:36 AM
----------------------------------------------------------------------------

AI summary:

AI: Eve will type up her strawman (wrt assn subj placement thoughts) and send 
to list.

AI: scott & tim & john to chat next week wrt particulars of these (kerberos 
related) items.

----

attendance (fwiw, no worries, not an "official" call)...

john hughes
tim alsop
eve maler
ron monzillo
paula austel
tony nadalin
mike macintosh
scott cantor
jeff hodges (notes editor)
peter davis
RLBob Morgan
rick randall


agenda bashing...

ended up with we'll discuss:
  authnreq protocol
  subject conf
  rel btwn prot&schema & bind&prots


----

ScottC holding forth on his thinking of normalizing use of AuthnReq/Resp across 
both so-called front- and back-channels (ed.'s words)

asserts that browser artifact profile is call-by-reference rather than 
call-by-value.

scottc's gonna recast the front-channel web browser profiles in terms of the 
authnreq approach this week and incorp in draft spec -- folks should review


eve: expressed wish that feature proposals be explicitly identified as such in 
messages on the list, such that they can get explicitly discussed on the concalls.

---

Ron asking questions wrt subject conf. can we seperate the authnreq discussoin 
from the mult-vs-single-subj-per-assn and related impact on subject conf 
discussion.

----

eve: is there a use case for mult-subj-per-assn?
   e.g. having

Ron: there's two use cases
  one is having an "conf/attesting entity" in addition to a "subject"


scott: have to be careful to sep discussion of what we want vs what we ahve today.

eve: we should be careful to sep "having the ability to factor out" vs 
"mandating that we're going to factor out subject with a new assn format"

rlbob: current saml specs say that if a colleciton of assns must mean the same 
thing if we cram them together, and the converse.

eve: agrees

rlbob & eve: we *could* change this.

eve: but we don't appear to have any use cases to do so.


RonM: if we move subj to the outer assn container, then what does that mean for 
subj conf?


scottc: need to figure out the mult-or-single-subj issue first, and _then_ 
decide about what to do with subj conf.  further we should sep subjconf and 
subj, but that's a diff discussion.


ron: agrees. but wonders about some of the details therein and the meaning of 
subjconf. thinks what we have is more "stmtconf" rather than subjconf.


scott: observes that by having subjconf be a part of subj ihtertwines the 
topics of subjs and confirming them, hence his thinking of splitting them.


ron: wondering about the relshp btwn confirming subjconf/subj
a saml assn is a cert, and the issuer is vouching for its content, once you 
have validated the subjconf, you are operating in a diff plane now.

there's validtn of the assn content, and then once you confirm the subj ident 
by confirming the subjconf, then you can then "use" all the rest of the content 
of the assn.

his point is that what we're really trying to do is confirm the name ident of 
the subject as well as all the other content of the stmt.

eve: there seems to be a bit of a disagreement btwn folks here and Rons 
position....

scottc: in summary there seems to be two use cases that'd get ruled out if we 
move subj to assn-wide. one is mult subjs about mult diff entities (no real use 
for this?), the other is mult subjs about same entity, but with diff conf methods.

eve & scott: noting that subjconf could be "promoted" to assn-wide optionally 
if its the same in all stmts.

scott: but if have a saml stmt that isn't about a subj, is more just a claiml, 
but if you think about subjconf as presently defined, its not clear how that 
applies to a stmt that reps some claim given our present understanding of this 
stuff [and we'll ahve to figger it out (ed.)]

ron: lets say you decouple subj from confmethod, and you add such a conf mthd 
as a conftype to every stmt, and you allow conftype to ref a confelement 
somewhere else, so you get the ability to ref it from mult places. but if you 
have a bearer meth in one place, and another stmt, then you can bind a diff 
conf meth to that stmt.


scott & eve & ron: [figuring it out]

eve in summary: so what yer asking about Ron is possible.


eve: stating a strawman:  will need to ck with Irving...

what if we promote subj w/o conf to assn-wide, and also contains a optional 
subjconf elem. stmts have an optional subjconf. in case where someone wants to 
extend saml, w/o assn-wide subj,  they can extend the subjassntype, but add 
conditions.


AI: Eve will type up her strawman and send to list.

-----

Scott: are the other points I made on the list wrt subjconf striking a chord 
with anyone? ie that the current approach is suboptimal?

Ron: essentially agrees.

scott: the content of subjconf is broken -- stuff in there he doesn't 
understand and what it might be used for -- eg both an "any" and a "keyinfo".

ron: wants to understand what the degrees of freedom are..... we seem to have a 
mess...

scott: agrees. having mult confmeths today is unspecified and a mess, so he 
proposes that in any confmeth elem, have one meth and some data,  and then you 
can have mult confmeths.

------

eve: talk about authnreq protocol?

scott: put concrete text in the spec to see how it looks and get some review. 
biggest area of discussion is about "what is this for?"

put in processing rules that said "you'll get back an authnstmt no matter 
what", wonders whether it should be an "assn req" protocol.

see sstc-saml-core-2.0-draft-06-diff.pdf, sec 3.4, line 1507, p 36.

need to work thru profiles of it and the front-channel bindings.


eve: seems like its a bit cart-before-horse having it in the spec without 
having worked thru the applications of it...

scott & rlbob: seems its pretty clear, and doubtful it'll be misunderstood as 
it presently is.

[general agreement that generralizing it to, eg, an assnreq _would_ be possible 
to misunderstand/use...]


ron: didn't quite understand what scott meant by "use case". but ron sees use 
for this authnreq, somewhat because the other existing saml queries dont allow 
one to say "i need an assn with these properties..."

scott: but there's subjconf in the existing assn queries which can be used to 
influence results.


ron: what about the returning "at least one assn stmt"?

scott & eve: can return any number of assns & stmts, don't constrain it. 
profiles of the protocol can constrain the results.

ron: was looking to this profile for doing something a little bit diff than authn.

eve: are you wanting to keep it in, and revising it there?

ron: kinda needs some generalization, but lets keep it there and refine as-is. 
but he wants to discuss and work thru his use case and figure out whether 
what's there applies or not and figure out the gap if not.

so where do things like kerberos fit in to this?

rlbob: kerb in the sense of getting a service ticket for an itermediary?

JohnH: willing to see if they can figure out how the kerb stuff they're doing 
can be built on top of the stuff scottc is putting into the spec.


AI: scott & tim & john to chat next week wrt particulars of these items.


------

johnH & rlbob & ron -- discussion of kerb profile detail stuff.

eve: we're out of time, we should continue this on the list.

============================================================================