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] FW: [saml-dev] Constrained delegation


I accept that the SAML 2.0 assertion structure is flexible enough for 
our purposes.

But I don't see how a relying party can assume very much just based on 
the presence or absence
of NameId in an assertion. That is where the profile fits in.

This was also one reason I focused on the constraints on SAML 
authorities and Relying parties in my example:

http://lists.oasis-open.org/archives/security-services/200601/msg00046.html



- prateek

> 
>
>  
>
>>These are good points; maybe the issue is more about 
>>capturing or recommending certain patterns of use vs. 
>>developing a new profile.
>>
>>But before we discuss solutions, here is a question:-:
>>
>>Is it important for SAML issuers and relying parties to 
>>distinguish between:
>>    
>>
>
>If I put X in the nameID in the subject confirmation am I not
>identifying that server X is actiong for Joe?
>
>If I don't put such a nameID, then shouldn't it be Joe
>who is doing the acting (or at least something acting
>as Joe as Joe probably isn't the computer application
>that is proving the HoK)?
>
>Conor
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>  
>




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