draft-ietf-pkix-ac509prof -> RFC?

Hideyuki Odahara <odahara@dsa.isl.ntt.co.jp> Wed, 30 May 2001 02:17 UTC

Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14984 for <pkix-archive@odin.ietf.org>; Tue, 29 May 2001 22:17:42 -0400 (EDT)
Received: by above.proper.com (8.9.3/8.9.3) id SAA01807 for ietf-pkix-bks; Tue, 29 May 2001 18:50:14 -0700 (PDT)
Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA01798 for <ietf-pkix@imc.org>; Tue, 29 May 2001 18:50:04 -0700 (PDT)
Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id KAA23320; Wed, 30 May 2001 10:49:45 +0900 (JST) (envelope-from odahara@dsa.isl.ntt.co.jp)
Received: from dsa.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id KAA27923; Wed, 30 May 2001 10:49:39 +0900 (JST) (envelope-from odahara@dsa.isl.ntt.co.jp)
Received: from cats by dsa.isl.ntt.co.jp (8.9.3/isl-2.0) id KAA12569; Wed, 30 May 2001 10:49:21 +0900 (JST)
Date: Wed, 30 May 2001 10:52:10 +0900
From: Hideyuki Odahara <odahara@dsa.isl.ntt.co.jp>
To: stephen.farrell@baltimore.ie
Subject: draft-ietf-pkix-ac509prof -> RFC?
Cc: ietf-pkix@imc.org
In-Reply-To: <3ADC3F64.895C47B0@baltimore.ie>
References: <20010410173741.DB73.ODAHARA@dsa.isl.ntt.co.jp> <3ADC3F64.895C47B0@baltimore.ie>
Message-Id: <20010530104344.4868.ODAHARA@dsa.isl.ntt.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00.03
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>
Content-Transfer-Encoding: 7bit

Mr. Stephen Farrell

Thank you for your reply the example of use of an attribute the other
day.
I would like you to teach about RFC-izing of draft-ietf-pkix-ac509prof
today, and mail was given. While it is said that ac509prof has near
RFC-izing, it is not RFC-ized easily. Now, would you the argument is
progressing how much and teach [ when to RFC-be due to beized and ] this
draft?
Although humiliated a busy place, I ask of you well.

thanks


> 
> Slightly late response, but here it is...
> 
> Syntactically, the access identity attribute can't have the authInfo 
> field present. This basically means that you should use the access
> identity field if the relying party is willing to believe a straight
> assertion from the AA about the holder's identity. In theory that 
> should be enough, but it turns out that there are many applications
> which still require a username & password to identify/authenticate
> a user, so the service auth info attribute allows support for such
> applications.
> 
> As an example of where this might apply, say you inegrate the AC
> relying party code into a web server, with a set of web applications
> being called from the web server. Now some of those applications
> will simply accept a user identity passed from the web server, using
> say the ssl client or holder field for identity, others will have their 
> own concept of usernames (so you can use the access identity for those),
> but still others will have their own username/password handling (so 
> you can use service auth info and not bother the user with entry of
> additional passwords).
> 
> Hope this makes it clearer,
> Stephen.
> 
> Hideyuki Odahara wrote:
> > 
> > Please teach me the difference of the use of
> > "Service Authentication Infomation" and "Access Identity"
> > in Attribute Certificate, and how to use the "Access Identity"
> > attribute if you have any concrete example.
> > 
> > It is described that "this is a different use to that intended
> > for the svceAuthInfo attribute discribed in 4.4.1 above." at the
> > page 19 in the internet-draft(draft-ietf-pkix-ac509prof).
> > But there is no example what situation does it suit.
> > 
> > thanks

----------
  Hideyuki Odahara : odahara@dsa.isl.ntt.co.jp