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-comment] XASP: Permitting use of Subject AltNames?


> Thanks.  Actually I was planning to suggest a URI for each of the
> GeneralName forms that needed one - SAML2Core already has
> nameid-format:emailAddress, URI is a URI, and I'm not particularly
> interested in profiling x400Address or ediPartyName :-).  If other
> parties are interested in defining URIs for, for example, IP Address,
> this would be the place to do so.  My immediate goal is to accommodate
> two specific OtherName formats: RFC 4043: Permanent Identifier
> (urn:oid:1.3.6.1.5.5.7.8.3) and FIPS 201: Personal Identity 
> Verification
> (urn:oid:2.16.840.1.101.3.6.6).

I'd suggest using separate URIs to specifically identify the two OtherName formats you're interested in, rather than a nameid-format:otherName that must then be further profiled for two possible content types.

> 
> I am working on the same applications that drove the original 
> XASP spec
> (see 
> http://www.defenselink.mil/releases/release.aspx?releaseid=11915),
> but it probably would be cleaner to base a new profile on 
> either XASP or
> X.509 Deployment rather than attempting to extend either of those.  

Is the idea to preserve the requirement for X.509 certificate-based authentication in a new profile, or merely to profile AttributeQuery with additional NameID formats?

::Ari


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