AuthnRequest proposal #2

[Scott Cantor <cantor.2@osu.edu>]

Thanks for the helpful comments (Ron especially), here's another stab at it
with some exposition on how things might work.

<complexType name="AuthnRequestType">
    <complexContent>
        <extension base="samlp:RequestAbstractType">
            <sequence>
                <element ref="saml:Subject" minOccurs="0"/>
                <element ref="samlp:NameIDPolicy" minOccurs="0"/>
                <element ref="samlp:ConfirmingSubject" minOccurs="0"
maxOccurs="unbounded"/>
                <element ref="saml:Conditions" minOccurs="0"/>
                <choice minOccurs="0">
                    <element ref="samlp:ForceAuthn"/>
                    <element ref="samlp:IsPassive"/>
                </choice>
                <element ref="samlp:RequestAuthnContext" minOccurs="0"/>
                <element ref="samlp:ProtocolProfile" minOccurs="0"/>
                <element ref="samlp:AssertionConsumerServiceID"
minOccurs="0"/>
                <element ref="samlp:Scoping" minOccurs="0"/>
            </sequence>
            <attribute ref="consent" use="optional"/>
        </extension>
    </complexContent>
</complexType>
<element name="ConfirmingSubject" type="saml:SubjectType"/>
<element name="NameIDPolicy" type="samlp:NameIDPolicyType"/>
<complexType name="NameIDPolicyType">
    <sequence/>
    <attribute name="Format" type="anyURI" use="optional"/>
    <attribute name="SPNameQualifier" type="string" use="optional"/>
</complexType>

A quick rundown of Ron's enumeration of the entities involved and how I
might imagine some processing rules emerging:

1. the entity requesting the assertion

Request <Issuer>, may be authenticated via a message signature, primarily
only a factor in terms of the binding, since the Response must be delivered
back to this entity. I suggest that in the absence of any <Conditions>
input, an <Audience> condition be included that specifies the Issuer. This
fits ID-FF semantics (Issuer=ProviderID).

2. the entities able to use the returned assertion

A sequence of 0 or more ConfirmingSubject elements. These are currently just
saml:SubjectType. Each one would specify an entity that should be able to
confirm the resulting assertion's subject confirmation(s).

Could be a NameIdentifier that directly identifies the entity plus zero or
more ConfirmationMethods that the entity would be expected to use. Can also
specify a Subject solely with a security token using KeyInfo or
SubjectConfirmationData.

Need to specify how an assertion looks if it can be confirmed by multiple
different entities/keys. I would suggest perhaps that we need to tweak the
schema so that each statement Subject can contain multiple independent
SubjectConfirmation elements each with a single method, instead of the
current schema that permits a single SubjectConfirmation with multiple
methods but only a single KeyInfo or Data container. Otherwise it suggests
each "confirmer" would have to have a different statement to confirm?

If no ConfirmingSubject elements are included, then the semantic would be
that the only confirming entity is the message sender (the entity
authenticating to the SAML authority), probably with a bearer/artifact
confirmation. If a ConfirmingSubject with only a ConfirmationMethod is
specified, then the subject is implied to be the message sender but a
stronger method could be specified.

Am also willing to say this distorts the semantics of SubjectType too much
and we should define a new type.

3. the subject of the returned assertion

Optional <Subject> element specifies the subject of the returned
statement(s). Actual statements based on profile or other TBD request
content.

Thought was to use the Subject's SubjectConfirmation to include security
token that authorizes the issuance of an assertion with this subject, such
as a previous assertion that is valid for the requester. This may be a
little iffy in the sense that there isn't really a confirmation method in
the usual sense being used, nor does this relate to the actual confirmation
method(s) in the resulting assertion (see 2. above). May instead want to
think of a more general container for all of this, with a NameIdentifier
being one possible piece of this.

If Subject is omitted, then the implication is that the subject be the
message sender.

NameIDPolicy is independent but related. Requester can specify the Format to
use in the result. This should be workable whether Subject is implicit or
explicit in the request. I believe the Liberty 4-way enum can be simplified
(at a small cost in size) by just using the URIs directly, and treating the
urn:...:unspecified format as Liberty's "any" value.

The remaining issue involves how to specify the "namespace" of a federated
identifier in the result. If a single relying party is intended, then a
single SPNameQualifier should work. With the possibility of multiple
audiences, not addressed by ID-FF, this may not be enough or may be
ambiguous, not sure yet.

4. the target services (audiences?) at which the assertion may be used

I specify this as a set of Conditions that would form the basis of the
assertion. This definitely has implications for some kinds of subject name
identifiers as far as multi-targeting of an assertion. Either a single
shared identifier has to be applicable or an encrypted identifier used with
multiple wrapped encryption keys included for each target. Would need to
allow EncryptedKey to appear > once for this, but probably that's a good
idea anyway.

As noted earlier, an absence of Conditions could be interpreted as requiring
at least an Audience condition for the request Issuer.

--------------

I think this is closer. Still fuzzy in places, but closer. I think the ID-FF
SSO semantics fall out relatively cleanly except for a couple edge cases.

Looking over the WSS question from my admittedly uninformed point of view, I
think STR's fit in most of the critical spots. Authenticating the message is
fairly self evident as is sticking an STR in the Signature KeyInfo. Using an
STR to specify the Subject works if we squint at the schema and ignore how
Subject is specified on the asserting end of this, but this may be a poor
way to do it. Similarly the case for the ConfirmingSubject elements. Main
hole in this seems to be on the Conditions end.

Some truly open issues (aside from all the previous embedded questions):

- define a condition to block/permit forwarding/proxying of token into a new
token?

- how to represent impersonation in the assertion if at all, and whether the
request influences this

- work through some use cases and sketch out what the messages might be,
obviously

I don't suggest that we hold up the basic incorporation of the browser and
LEC messages we need into the spec, they shouldn't need to wait for this to
finalize. I further suggest we need to resolve the browser profile
differences soon and start on the non-SOAP message bindings we need, such as
URL encoding, form POST, and artifact.

Separately, I have a metadata schema draft I'll try and post shortly.

-- Scott