Subject: [dix] RE: attribute assertions

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Jan 2006 19:00:53 -0800

> If a site wants my email address, my blog URL, a link to my 
> buddy icon etc. SAML is more horse power than I need to 
> automate the exchange of that identity data. The use of SAML 
> requires an XML parser. Name / value pairs are all that are 
> required to move this simple data.

OK we can simplify things massively for a very small subset - where the
data being asserted does not have to be trustworthy.

Sounds to me like you are talking about a vcard type format. 

> Which makes you wonder why RSA makes you sign the license. 
> The issue is the barrier created by having to execute their license.

Probably because like me they are facing giving three to five
depositions in various patent infringement lawsuits this year, many of
which probably don't even involve RSA as a plaintiff or defendant.

The really iniquitous part of the patent process is the way that we all
get forced to participate simply to protect ourselves. During the design
of XKMS I had several design ideas vetoed on the grounds they were too
clever, someone might have patented them. I am currently dealling with
the legacy of something like 100 patents that make claims that relate to
my work, none of which are mine.

> I like the Apache IPR terms myself.

The Apache license is a copyright license, not a patent license, there
are different issues. What the IPR holders are trying to do here is to
establish a GNU like poison pill that requires other vendors who might
make IPR claims to offer equivalent royalty free terms. 

The Apache group participated in the W3C process that led to the
development of their IPR terms. 

> I think there is more to identity exchange then those two 
> points. I break it down as such:
> 
> 1) Discovery: negotiation between the parties on how to 
> communicate and capabilities
> 
> 2) Authentication: the user proving who they as you discuss above
> 
> 3) Attribute exchange: retrieving one or more attributes. In 
> essence a query. I think there should also be a way to store 
> attributes.
> 
> 4) Attribute schema: the method of describing the 
> attribute(s) to be exchanged
> 
> 5) Verification: the process of checking if one or more 
> attributes are "trustworthy"
> 
> I think there is lots of stuff that solves (2). I think there 
> are some standards for the others, but it is not all well 
> glued together as you mention.

That makes things a lot clearer.

If we can solve 1 & 2 we have an 80% solution for the blog single sign
on problem. We can take it to a 90% solution by adding limited support
for attributes. We can expect organic growth to take it the rest of the
way using SAML and third party issued assertions. 

I would strongly suggest people look at the power of DNS SRV records wrt
discovery (point 1).

As far as negotiation is concerned I tend to favor single round 'best
offer schemes' over attempts at multi-step convergence such as was
attempted in PEP etc. 

As far as authentication goes I think we need to have _a_ secure way to
support 1) passwords (including one time passwords), 2) public key
(including smartcard) and some form of extension mechanism to allow
people to plug in biometric. I would prefer to co-opt existing schemes
rather than co-opt a meta-negotiation scheme.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Mon, 16 Jan 2006 19:29:08 -0800

> data being asserted does not have to be trustworthy.

I would argue that it is likely a much larger subset then you suspect  
for online transactions.

> development of their IPR terms.

I was referring to the patent licenses in the copyright licenses.

> I would strongly suggest people look at the power of DNS SRV  

I like DNS SRV. There are simpler discovery processes though that put  
control where people feel they have control.

> offer schemes' over attempts at multi-step convergence such as was

agreed

> rather than co-opt a meta-negotiation scheme.

I still don't think that we need to worry about that. I see  
Authentication as a conversation between the user and their agent.  
The agent may be a website or their own machine or their phone. This  
likely will be clearer to you when you see bits.

---

From: "Suresh Venkatraman" <[email-masked]>
Date: Tue, 17 Jan 2006 02:54:01 -0800

> control where people feel they have control.

I think this should be a given, but is then a new protocol in order to
describe such a service in a DNS SRV record? 

      _Service._Proto.Name TTL Class SRV Priority Weight Port Target

> likely will be clearer to you when you see bits.

I'd prefer decoupling authentication/identity from its use by services which
require authentication and maintain authorization info (HTTP or SIP). My
assumption is that SSO will work across all services, not just for
browser-based apps.

The scenario I'm thinking of would be something like this: A UA asserts an
identity to the phone system to log-in using some yet to be described
identity exchange mechanism. Later, when you get a new phone system, you
just plug it into the existing framework. The user logs on and continues
without having to rebuild password information.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick
Hardt
Sent: Monday, January 16, 2006 7:29 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]; John Merrells
Subject: [dix] Re: attribute assertions

agreed

---

From: "Duane Nickull" <[email-masked]>
Date: Tue, 17 Jan 2006 09:22:14 -0800

All:

I get around 600 emails every 24 hours and find it difficult to wade
through them.  Before you hit "reply to all", please think about whether
or not the individuals are also on the list.  I am getting two copies of
some emails.

Thank you.

Duane

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************

---

From: "Duane Nickull" <[email-masked]>
Date: Tue, 17 Jan 2006 09:24:09 -0800

"I'd prefer decoupling authentication/identity from its use by services
which require authentication and maintain authorization info (HTTP or
SIP). My assumption is that SSO will work across all services, not just
for
browser-based apps."

I *very* highly concur.  No one should introduce unnecessary
dependencies.  That would be (architecturally) bad IMO.

Duane Nickull

---

From: Doug Royer <[email-masked]>
Date: Tue, 17 Jan 2006 10:31:26 -0700

Perhaps the list administrator can set the Reply-To to be set
back to the list?

I try to remember to do this manually when posting to lists.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

---

From: John Merrells <[email-masked]>
Date: Tue, 17 Jan 2006 10:12:48 -0800

> or not the individuals are also on the list.  I am getting two  

Reply-To was set to the individual poster... I've switched that so that
Reply-To is now to the list.

John

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Jan 2006 11:24:12 -0700

> Reply-To is now to the list.

Dear god please let us not start a thread on the evils of Reply-To 
Munging, shall we?

(That said, my understanding is that IETF policy is to forbid Reply-To 
Munging for WG lists.)

Peter

---

From: John Merrells <[email-masked]>
Date: Tue, 17 Jan 2006 10:27:56 -0800

On 17-Jan-06, at 10:24 AM, Peter Saint-Andre wrote:

> (That said, my understanding is that IETF policy is to forbid Reply- 
> To Munging for WG lists.)

Peter,

Yeah, I'm starting to regret it already.

John