OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

imi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [imi] Token profile issue with AppliesTo and AudienceRestriction


Anthony Nadalin wrote on 2009-12-16:
> So the parameters on the RST MAY be returned on the RSTR (which means that
> the STS may have not honored the RST), so I don't see anything in the IMI
> profile that would profile this allowed behavior, so right now an STS
could
> override anything that is in the RST and still be within bounds, the RSTR
> should be checked to see if what is requested is what is returned.

I've never seen that expressed, but if there's a mechanism by which the
client can determine whether the assertion it was issued is properly
constrained, that's a good thing, irrespective of what the profile says.

But none of that argues against specific token profiles imposing specific
requirements on the STS. That's what standards do. When they don't, they're
interoperable in theory only.

Not all policy has to be left to the IdP's discretion, even if some is.

> You can  have the case where the entity requested a Kerberos Token for
> Application X and sends the RST over to the STS and the STS knows the
policy
> (Application X MEX Endpoint)  from Application X and Application X does
not
> support Kerberos only UNP so does the STS fail the request or return a UPN
> token and allow the entity to continue

It fails. If not, the token type shouldn't be something you can ask for.
 
-- Scott




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]