Notes from SSTC Focus Group Agenda, January 13, 2004

["Eve L. Maler" <Eve.Maler@Sun.COM>]

(Please let me know if I got any details wrong.)

Attending:

Tim Alsop
Scott Cantor
Jeff Hodges (partial)
John Hughes
Rebecca Lepro
Eve Maler (note-taker)
Mike McIntosh (partial)
Prateek Mishra (chair)
Ron Monzillo (partial)
Tony Nadalin (partial)
Darren Platt
Frank Siebenlist
Von Welch

(Prateek has not yet sent out a proposal for W-5: SSO Profile 
Enhancements, so we didn't discuss it on this call.)

			*		*		*

Discussion on draft-sstc-attribute-02.pdf (Rebecca Lepro):

http://www.oasis-open.org/apps/org/workgroup/security/download.php/4884

The original "attribute" work item has been broken down into subparts 
over time.  There have also been some anticipated interactions with 
other work items, such as W-2 (nameid).

In Section 2.1, what is meant?  Is this about stuffing multiple values 
into a single statement vs. providing them marked up separately? 
Currently, there's some ambiguity about how to do this; people can do it 
either way and we provide no guidance.  An extension schema (as 
mentioned in lines 47-48) ends up providing application-specific rules 
about this.

We think it would be sensible for SAML itself to be more prescriptive on 
this point.  We have a repeatable AttributeValue element now, but we 
don't yet say anything about when/how to use it.

There's also an issue, not mentioned here, about what to do with 
empty/null values.  We certainly don't want to get absence of values to 
be confused with empty-string values (though note that AttributeValue 
currently has a mixOccurs of 1).

Section 2.2 doesn't quite highlight the fact that implementors (mostly 
Prateek and Rob) have reported usage of AttributeNamespace for a 
scope-like purpose.  We'd like to be more prescriptive about how to do this.

AI: Rebecca to mention the AttributeNamespace usage in the next version 
of the paper.

Section 2.3 suggests that the attribute issuer be captured.  This would 
be in addition to the assertion issuer.  Rebecca isn't sure she supports 
this requirement anymore; she goes back and forth.  Bob Morgan sent a 
message recently in opposition to this requirement:

http://lists.oasis-open.org/archives/security-services/200401/msg00036.html

Scott notes that without a signature, indicating the attribute (vs. 
assertion) issuer is meaningless.

Because the solution proposal provides an easier way to set the 
attribute type, it pushes off the need for attribute issuer information 
a little bit.

Prateek's company doesn't have any use cases for 2.3, and it does add 
complexity.

The current NameIdentifier proposal could be used here.  How would we 
inform users of this option?  It would be non-normative.  We could 
publish a white paper, or the community that wants to supply attribute 
issuers (assuming it's not us) could publish a normative or 
non-normative document on this.  We're not sure who the interested 
communities even are.

Eve suggests that Rebecca decide if she'd like to yank this requirement, 
based on the non-enthusiastic reception on this focus call, and reissue 
for consideration of the whole TC.

Section 2.4 points to the need to express value type information on the 
Attribute element rather than the AttributeValue element.  XACML 
expresses type information in its own URI-based language, whereas SAML 
uses XSD mechanisms.  What's the right way to make XACML and SAML 
attributes talk to each other?

Scott suggests that we first have to talk about how to uniquely name 
attributes, which has an impact on the typing problem.  They are not 
distinct from each other.  This relates to the one-part vs. two-part 
naming discrepancy, but is broader than just the technical issue.  There 
are some philosophical mismatches between the two specs right now.

In XACML the attribute ID and the attribute datatype must match, and it 
doesn't support non-uniform multivalued attributes.  SAML ended up 
allowing this latter situation, but sort of by accident.

Eve wonders if we should move in a direction that more consistently 
adheres to the LDAP paradigm.  Scott believes that SAML is pretty 
consistent with the LDAP paradigm, in that it provides the datatype at 
the point where it directly applies.

The issue, then, is whether SAML thinks it should move in a more 
XACML-compatible direction; this applies to both 2.4 and, in part, to 2.5.

AI: Eve to ask Anne Anderson for the historical use cases that underlie 
the XACML decision to use a URI-based type system.

Is it interesting/feasible to allow for both type representations? 
Rebecca has left the original mechanism in her solution proposal 
precisely to preserve backwards compatibility.

Scott doesn't really object to adding a datatype attribute to the 
Attribute element with a URI value, but would we reference the XACML 
specification for the universe of URIs to use there?  Eve mentions that 
XSD datatypes can be referenced by URI (though it pretty much requires 
setting ID attributes on <xs:complexType> and so on -- we might want to 
add IDs to our schemas for this purpose), and RDF types can also be 
referenced by URI.

The solution proposal indeed already proposes an addition of a 
URI-containing attribute, so it doesn't need to be modified on this 
score.  If we ultimately accept the proposal, we'd want to 
non-normatively reference various sources of datatype-related URIs.

Section 2.5 discusses the compatibility issue head-on.

Scott notes that reusing AttributeNamespace for datatyping at the 
Attribute level might clash with others' existing reuse of 
AttributeNamespace for scoping.  Rebecca would like to hear more 
comments about attribute identity.

AI: Prateek, Eve, and Scott to comment on the TC list about the solution 
proposal, in order to get us ready to make decisions in next week's call.


			*		*		*

Discussion on draft-sstc-solution-profile-kerberos-01.pdf (John Hughes 
and Tim Alsop):

http://www.oasis-open.org/apps/org/workgroup/security/download.php/4966

John suggests reviewing the dialog that's been happening on email, 
rather than walking through the document section by section.

The main idea is that you can do a query to get an authentication 
assertion.  John is proposing this, and Scott notes that Liberty's 
<AuthnRequest> is designed to do exactly this, and that Liberty's 
browser profiles map pretty closely to what's being proposed here. 
Today, there's no normative restriction saying how the browser (or 
whatever) authenticates to the authN authority.  John would like to 
specify how that goes.

Figure 2 in the proposal suggests that SAML V2.0 can standardize the 
interaction between the browser and the SAML service.  At the level of 
the transport protocol, it would be specific to the (e.g.) Kerberos use 
case.  Scott would want to cast any non-SOAP interaction at this level 
as a new SAML protocol binding.  The point, he believes, is to cast the 
higher-level interaction as just another case of the SAML protocol 
exchange that we already have as a work item.

Ron asks whether the purpose of this profile is to show a bridge between 
Kerberos and SAML, or to show how a SAML authority can be used in a 
Kerberos style?  John confirms that his interest is in showing use 
*with* Kerberos.  Jeff says Scott's point seems to be that we could 
generalize this approach, where Kerberos is just one option on the 
source site.  Ron says this was behind his question.

Scott points out the implications for intermediaries and "forwardable 
assertions" here.  He wants to recast the browser profiles to reflect 
the more general nature of bearer assertions (and artifacts that are 
references to them).

Ron thought that what would happen is return of an assertion with the 
holder-of-key mode.  That would make SAML act like a KDC.

Prateek notes that the current browser profile works between two 
arbitrary kinds of domains; no one need care what the IdP has 
implemented for its authentication structure.  If, at the IdP, there's a 
Kerberos implementation, he's not sure what part of that we need to 
expose into the SAML profile.

The answer: It's an increase in interoperability for the interaction 
where the client side has a Kerberos credential.  The arrow between the 
browser and the SAML service in Figure 2 is the key, though for the 
browser case specifically, the solution isn't as interesting; Scott 
suggests that ensuring that the non-browser general case is covered 
(with a new non-SOAP protocol binding) is where the power is.

Browsers don't currently use Kerberos credentials, except in a very 
HTTP-specific way.  So another thing this solution proposal does is to 
improve on interoperability between Kerberos credentials on a client 
machine and the browser's usage of this.

Scott and Prateek are not sure where SAML really fits in to this 
solution, other than pitching something over the wall to someone else.

Ron thinks this use case may resonate with other use cases that require 
an AuthnRequest.  If we're requesting an assertion that's confirmed in a 
certain way, it starts getting more tightly coupled with the 
authentication method.  Scott says that if you stick with bearer 
assertions, it doesn't seem to need a lot of design effort, and Ron agrees.

Ron recalls/believes that the TGT has your session key in it, so to some 
degree in this Kerberos case, you have a convenient way to do a 
key-confirmed assertion.  If the session key is returned, you could use 
that.  Tony agrees.  Scott points out there's some overhead with this.

If the SAML service signs the assertion with the session key, only then 
would the remote site care about that key.

The next step is that we need to make progress on the AuthnRequest, 
which is Prateek's bailiwick!  We think we should start with the Liberty 
design plain and simple, for starters.

John wonders if this solution proposal should keep to the minimum 
details and then just point out to the existing AuthnRequest design. 
There seems to be general consensus on this point.  This introduces a 
dependency, but seems cleaner overall.  Jeff will point to the latest 
much-revised draft of SASL-based authentication over SOAP when it's 
publicly available.  Liberty sponsor members will have access to this 
next week.

Scott suggests that WSS needs to be looked at here, as well.

It sounds like we need some of this work to be covered under the SSO 
Profile Enhancements work item.

AI: John to evolve the proposal in a direction he assures us is 
understood to him. :-)

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com