I'm not too bothered about examples, rather I was curious what was meant
by a session id. Now I know (sort of).

I get the impression it would be very easy for an IdP to work out what
user is being referenced, given, say a NameIdentifier and AssertionId. A
simple grep of the logs would be enough. Or is that too simplistic a view?

The hard part is the SP locating that information in it's own logs and
matching those tokens to a flame post in a shibbed message board for
example. I presume that's what all this is for?

That's why I thought it was an "extension" to the shibb profile. If it's
IdP/SP specific, rather than the fed laying down the interaction profile,
it could get very messy for an IdP to log everything all its SPs might
want.

Almost like an arbitration profile. "You got a complaint? Take this, this
and this to the IdP and get this back". It would also make it clear what
the software must support to satisfy section 6 logging as presumably other
feds will have different criteria in this area.

Alistair

-- 
mov eax,1
mov ebx,0
int 80h

> Tom Scavo wrote:
>
>> I'm sorry, Ian, I must be misunderstanding something.
>
> I started off doing a point-by-point on your message, but I think the
> crux of it may be that you're reading section 6.5 as requiring the IdP
> to be able to isolate the particular assertions made to the SP, whereas
> in fact the intent is simply that the IdP is able to isolate the *end
> user* responsible.
>
> If we were concerned with trying to isolate the particular assertion,
> then your remarks about the (potential) non-uniqueness of subject
> identifiers in the log files would be completely on point.  For the
> purposes of user accountability (wich is to say, identifying the end
> user, not the assertion), though, they're irrelevant.  For example, if
> the subject identifier is the user's X.509 DN, then that makes it
> *easier*, not harder, for the IdP to figure out which user is involved.
>
> I'm prepared to believe that this intent isn't as obvious from the text
> of the Rules as we might have hoped.  Trying to put technical concepts
> into legal language without over-specifying things turns out to be
> really, really hard.
>
> If people feel it is necessary, we could probably add some
> clarifications to the Technical Recommendations giving examples of the
> sort of thing you'd need to log to be in compliance, and what the SP
> should log if they wanted to take advantage of it.  I'd like to avoid
> turning the TRP into a manual for particular software, though, and
> making recommendations in this area would require us to look at what the
> different implementations actually had the ability to log, so it
> wouldn't be an instant change.
>
> 	-- Ian
>