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] | [Elist Home]


Subject: Word smithing RE: Request for clarification


Title: Request for clarification
 All,
 
        Here is what I have currently on the Authentication assertion. It is mainly drawn from Prateek's draft but reworded somewhat to follow the style of the specification as a whole.
 
    One thing I am somwhat fuzzy about is the party that is doing the issuing. It seems to me that this is implicitly the issuer, however the Authlocale element appears to restate this but is optional.
 
        Phill

1.1            Authentication Assertion

An authentication assertion asserts that the subject was authenticated by the issuer by a particular means at a particular time.

1.1.1       Assertion Type AuthenticationAssertionType

The AuthenticationAssertionType extends the SubjectAssertionType with the addition of a required AuthenticationCode element a required AuthenticationInstant element and an optional AuthLocale element that specify an authentication event as follows:

<AuthenticationCode>
The <AuthenticationCode> element specifies the type of Authentication that took place.

<AuthenticationInstant>
The <AuthenticationInstant> element specifies the time at which the authentication took place.

<AuthenticationInstant>
The <AuthenticationCode> element specifies the DNS domain name and IP address for the system entity that performed the authentication.
 

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, July 26, 2001 11:22 AM
To: 'Kawamoto, Shirley'; Security-Services (E-mail) (E-mail)
Subject: RE: Request for clarification

If you refer to the Domain model: http://www.oasis-open.org/committees/security/docs/draft-sstc-use-domain-05.pdf
you will see that what you are asking about is a Credentials Assertion.
 
The Authentication Assertion is a report of an authentication event which occured in the past. The request for an Authentication Assertion is not in of itself an authentication act.
 
The TC voted to break off the work activity around the Credentials Collector and Credentials Assertion into a separate sub group. This group is being led by Stephen Farrell. There have been no recent reports of progress by this group. If you are interested in this area you might want to contact Stephen and offer to help.
 
The way SAML is intended to work at the moment is the authentication occurs between the System Entity (typically a user) making a request and the Authentication Authority, by means specified outside of SAML, e.g. HTTP basic authentication, SSL with client certificates, etc. Other entities can request an Authentication Assertion describing that event as well as Attribute Assertions describing the System Entity.
 
Hal
-----Original Message-----
From: Kawamoto, Shirley [mailto:SKawamoto@hitachisoftware.com]
Sent: Tuesday, July 24, 2001 2:17 PM
To: Security-Services (E-mail) (E-mail)
Subject: Request for clarification

As someone who is new to this group, I hope you'll forgive me for asking some questions that may have some obvious answers.

If a user is authenticating via userID and password, where is the password passed in the authentication query? What form does it take?

If a user is being authenticated with public key techniques (but something other than SSL client authentication) where are the challenge and the signature on the challenge stored? What form do they take?

Thanks,
Shirley

Phillip Hallam-Baker (E-mail).vcf



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


Powered by eList eXpress LLC