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] Drafts for review: Kerberos & SAML profiles


A couple of queries...

> Josh Howlett wrote on 2009-06-23:
>> Please find attached three draft profiles.
>>  - Kerberos Attribute Profile 00: defines an attribute profile of
>> Kerberos.


> Then you add language indicating that for purposes of value  
> comparison, an
> empty value is considered equivalent to a populated ticket value iff  
> the XML
> attributes match. That satisfies the need to use the existing query  
> protocol
> to request tickets based on those attributes (including multiple  
> differing
> tickets).

Just to check my understanding, am I correct in thinking that this is  
intended to satisfy the following: (SAMLCore, Element  

"If a given <saml:Attribute> element contains one or more  
<saml:AttributeValue> elements, then if that attribute is returned in  
the response, it MUST NOT contain any values that are not equal to the  
values specified in the query."

>>  - Kerberos Holder-of-Key Assertion Profile 02: defines how to
>> confirm an attesting entity using Kerberos.
> I haven't studied this one in detail yet, but my immediate reaction  
> to this
> is to wonder if it's really beneficial to call this HoK vs. just  
> defining a
> Kerberos-specific confirmation method with an attendant syntax for the
> confirmation data to specify the Kerberos principal name, as you  
> suggest
> here via KeyName.

That's an interesting idea. It certainly seems simpler than grafting  
Kerberos onto the HoK AP. Are there are any reasons why we would not  
want to do this?

best regards, josh.

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