2005.03.02 Yale Discussion

Owned by Andrew Petro
Last updated: Mar 02, 2005Version comment

Present:
Andy, Howard, Susan, Drew, Andrew

Howard on Client certs

How tickets convey the Subject (or Principal) they authenticate:

  • RFC 822
  • DNS
  • DN
  • uid?

ASN.1 becomes XML

Namespace URIs?

WIND / Columbia

ACTION ITEM: Susan will post to Wiki about how to implement WIND extensions on CAS 3.

Strength of authentication

At Login application expresses a scalar strength of authentication requirement or a particular desired authentication mechanism identified by a local key. CAS will only redirect back with a ST once the desired level or particular authentication mechanism is achieved. This provides no actual security, just provides for a compelling user experience – the user might hack the metadata on the Login request about strength preferences. The level and authentication mechanism is expressed in the (SAML) ticket validation response (which is securely vended) and so applications can actually require a particular level of authentication.

What we're going to do

Write a new login controller implementing our non-interactive authentication ideas.
Howard will do this but as Howard is out Thu through Tuesday (back Wed) Andrew will take point on producing a Proof of Concept for Monday's Yale CAS meeting and having a place for Howard to plug in some actual certificate extraction and parsing for Wed.

  • Added to Video Conference agenda for next vid conf.

CAS2 Spec

We had a 2nd draft and on Monday we discussed edits to that draft. Given a few uninterrupted hours Drew could get a Release Candidate of the spec written.

Agenda for Monday

1) Andrew shares result of non-interactive login controller implementation foray.

2) We all examine how the requirements represented by ACAS can be implemented using CAS3.