SSTC F2F #3, Newark, CA 2001/06/25 RL "Bob" Morgan --------------- didn't make quorum, grumble Hal on issues list very few issues "marked in yellow", meaning ? 3 new bindings issues need a way to put resolved issues on the side bindings report, Prateek distinguish binding from profile binding is "how to make SAML exchange happen, using underlying foo" profile is "how to make foo exchange happen, with added SAML elements" binding is "how SAML uses foo" profile is "how foo uses SAML" there will be few bindings, there will be many profiles profile is how to use assertion in some unforeseen context HL: so expectation is that bindings will be re-used across protocols? PM: sure, but that's not the main point folks come to agreement on this distinction but don't really like "profile" word conformance mumble recent "crypto flaw in secure email" as example of "consideration" sessions timeout is the main problem "extent to which site plays in protocol only affects their own risk" issues of target sites "not liking" authn policy/method provided eg target wants 15-min timeout, user-authn site does 30 so ... target shouldn't use that authn site, hmm DO: push vs pull depends on whether global or local timeouts are shorter BB: need to do interaction/timing diagrams showing various possibilities, and how we want it to work so we can design to that editor's report, BB still much ado about whether one doc or many JH: how about many docs while we're still meeting about them assertions PHB proposals are meeting in the middle? the query thing typical SAML query has a unique subject that it's about? this is "SAMLSubjectQuery" but "give me assertion with ID " doesn't have subject? so this would be a different type? new less-constrained SAMLXQuery could be another type ... "subject" doesn't necessarily mean "this well-identified principal" could just be "set of attributes", no? hmm DO "constrain early and often", hence top-typing re-use vocabularies use attributes define cardinalities for all assertions ie, subjectAssertion has exactly one since saying 0..* is just too damn loose for type-safety assertions not re-used for queries but if they are, then need additional types use of "any" element in XML schema provides "wildcard" subjectAssertion is new type, has, duh, a required Subject SAML attributes are "vocabulary specific" meaning can't predict so identify them by namespaces, using wildcard these attrs can be in their own attr language followup activity to SAML as protocol would be standard SAML schema defs, ala LDAP, hmm attributes shouldn't be constrained could in their fullness be XML documents EM: authz assertion is still not agreed to might be just part of decision-request please give me answer about subject with these permissions might be just part of decision-response Yes, and subject has these permissions the web browser SSO thing, Prateek scenario is the local-nav-site-first thing where "handle service" is "inter-site transfer service" design a reference-like "elementary artifact" dest uses artifact to get real authn assertion nature of "one-use" this is basically advice to relying parties: don't expect to replay this securely proposed "artifact" has a type code, so could define others has a pointer to real assertionID, via "partner ID" and assertion ID "partnerID", 32 bits, identifying issuer "assertionID", meaning artifact handle, 64 bits specifically unsigned artifact handle must be unguessable, this prevents forgery note assertion could be attr assertion, hmm? so Shib "query handle" could be handle of assertion, hmm? what about protection against abuse by destination? well, issuer knows who destination was spose to be so can reject query for that handle from bogus dest, hmm authn assertion boardwork, Bob B the thing itself, and query/response authn assertion contents subject which could be complex thing authn method issue instant and all the other stuff, like issuer BB: authn authority "views" events from real authn service applies index numbers to them, maybe does other packaging does issuer define the domain? if not, also need domain HL: only sensible request is give me (unexpired) assertions about subject foo or about assertion foo can a set be returned, not just one or none? does "unexpired" mean "valid"? so, ask "via method foo" in query? which we'll call "authn type"? does this have to be "any of this list", or "all except this one" how about limiting it to: "this one" or "any" we can agree on this, yay someone wants "namespace" as param is that sposed to mean "security domain"? what is it the namespace of? the authn authority? the authn service itself? and what is its syntax? flat or structured? separate namespace lets you encrypt/obfuscate username separately does it have a "type" in itself, in addition to its value for each param there's the argument: the church of identifier syntax URI, string, OID, type/value pairs, XML doc, other? authn type SAML has to have a registry of them? there won't be very many? lookup by assertionID the thing proposed in browser case isn't this ID exactly so that profile has to say how to map? but the relying party has to do this mapping? hmm assertion ID syntax? much harangue about this Jeff thinks it can just be binary blob, PBH wants URI no other params necessary (is there a general "query by assertion attribute/envelope") conditions and advice and critical extensions how best to ensure all of: extensibility to meet lots of requirements interoperability among implementations and deployments "audience" is the condition poster child separate "must understand" semantic from extensibility PHB: calling them "conditions" is meant to indicate to ordinary humans what these are, since the ML theory is that that might be necessary some time. hmm. so calling it a "condition" may not change the code any ... ? conformance, Robert Griffin, Entrust text in spec itself to say what conformance means then separate docs on conformance itself ? "partition" (ie, not profile) break it up by components, describe what they have to do levels of behavior is harder to do, so avoid for now? which bindings to implement is another thing levels of compliance just running tests yourself = "conformance testing" next day issue: can you designate a subject using assertion ID? attribute query things to ask return attr-assertion with all attrs for specified subject return a-a with selected attrs for s-s return a-a with this assertionID is it assertion(s)? can an AA provide assertions from multiple issuers? obviously a single assertion can't be split up ... are assertions groupable? is (A, B) same as (A), (B) ? obviously forwarding is different what is indication when request is for specific attrs and AA doesn't give them all back? is an error indication given to requester? BB: have to, else requester gets confused? is it necessary to support "all or error" kind of request? attr assertion contents 0 or more assertions each assertion has one or more names each name has one or more values does it have to have "who it's about?" ie subject are the subjects of attr assertions always principals? hmm, maybe not, but attr-a subjects should always be the same subjects as authn-a subjects, yes can the subject of attr assertion be assnid or assertion? or should it always be subject-as-extracted-from-that-assertion it's weird for AA attr specification HL: only need to specify "all" or list of attr names avoid context/subtree etc IR: moreover, attr names should be strucureless hence no wildcards or parts or anything HL: scoping and naming, sigh people are arguing about scoping of attr names subject name is security_domain plus name(id)_in_that_domain attribute expression attribute name (syntax specified by XML namespace) attribute value attribute security domain ? is this a recreation of LDAP? or of LDAP plus an admin model? ick authorization decision assertion the request is should operation Y on resource Z be allowed, given evidence E, possibly including subject S request subject specifier (required but can be empty?) (subject) assertions should subject of these assertions be required to be the same subject as the subject of the subject specifier my example: it would be useful to include: attr assertion saying issuer of attr assertion A on the main subject has attribute "really good issuer" HL: issuers aren't subjects ? action and object object can be URI, no? how about action? just a string, with default set be r/w/x/d/c ? or is the above xmlns:file-action-namespace ? where other namespaces might be http, ftp, ejb, whatever? authorization decision assertion yes/no replicate request params? seems like a good idea