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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: RE: [security-services] RE: AuthnRequest

So in effect the raw reference/Artifact would be carried back given what
ever GSS-API/Keberos etc bindings we would specify

I think we can live with that


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: 12 March 2004 15:28
> To: 'John Hughes'
> Cc: 'Security-Services'
> Subject: [security-services] RE: AuthnRequest
> > when I started to initially develop the KRB use cases it transpired that
> > <AuthnRequest> would satisfy part of the requirements.  In particular by
> > being able to obtain an assertion for the requesting principal or an
> > Artifact/reference to an assertion.  Having just re-read the latest core
> > spec I can't determine how an Artifact/reference could be returned.
> >
> > Could you (hopefully) point out how this this requirement is
> > satisfied.
> It's my view that this is a binding issue, and the AuthnRequest
> contains an
> optional ProtocolBinding element to allow a requester that
> supports multiple
> bindings to specify the one it wants.
> If a requester only supported one, it could leave this out and
> the responder
> would use the requester's metadata to find out which binding to use.
> The one thing this doesn't support is explicitly getting an assertion by
> reference as opposed to a response by reference (the artifact). We could
> address this by changing the Response content model to permit returning
> Assertions or AssertionIDReference/AssertionURIReference elements.
> -- Scott
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to

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