RE: [saml-dev] claim renewal url

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

> I'm using saml:Assertion to represent a third-party claim.

In most cases, all assertions tend to be third-party claims, assuming you
count the subject and the relying party. I'm guessing you mean a fourth
party, somebody other than the one issuing an authentication assertion as
input to a session, as in SSO.

The structure of an assertion doesn't directly accommodate it, but one could
imagine enclosing signed assertions from another issuer alongside a new one
in a message, or embedding them as attributes of an enclosing assertion.

> I have a set of claim data that I've mapped onto the saml:AssertionType
> elements. But, I have a piece of claim meta-data that's related to the 
> claim, but shouldn't be in the claim.

I hate to ask the question, but what do you mean by claim? ;-)

I mean, if you put it in the assertion, then in some sense, it's "inside". I
tend to think of a claim as a SAML attribute, mostly, so you could include
lots of metadata without putting it inside any particular individual claim.

> It's the URL where an updated claim can be
> retrieved from once the claim expires. This should be excluded for
> increased privacy.

What do you mean by "excluded"? Presumably it's optional, but either it's
represented somehow or it's not, right? But it's hard for something like
that to be "secret". I think the protection is usually on getting the data,
not knowing where it might be asked.

> Where could I put this? Is there an existing class
> above saml:Assertion that I could put this in? Or do I need to specify
> one myself?

In SAML alone, one tends to rely on SAML metadata. If you know the issuer of
a claim (let's call it an attribute to be concrete), then you usually have
metadata (or you can fetch it) for the issuer based on the providerId that
names the issuer. From that you can get endpoints of services offered, like
a SAML Attribute Authority, or potentially anything you extended the
metadata schema to represent. That's why I say it's not a privacy issue. I
can probably get the metadata, but that doesn't get me an updated assertion
unless I'm authorized to get it.

The same kind of information could certainly be passed in an assertion, in
multiple ways (Attributes, Advice, an Extension). In fact, SAML 1.1 used to
have an "AuthorityBinding" element for passing along this kind of thing
inline, but with the metadata added, it wasn't much use.

If I'm reading you correctly, it sounds kind of like you're trying to put
this "outside" the assertion itself, and of course at that point you're into
the protocol or possibly an application layer. SAML protocol is one vehicle,
and there's extension capability there, or you're talking some other
protocol entirely.

-- Scott