From nobody Mon Aug 4 06:01:49 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318E91A0386 for ; Thu, 24 Jul 2014 18:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBLoXN-mf4bc for ; Thu, 24 Jul 2014 18:23:54 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D379C1A0360 for ; Thu, 24 Jul 2014 18:23:53 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-37-53d1b1a827fb Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.33.01660.8A1B1D35; Thu, 24 Jul 2014 21:23:52 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6P1NqHp013426 for ; Thu, 24 Jul 2014 21:23:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6P1NovW014475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Jul 2014 21:23:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6P1Nojh006823; Thu, 24 Jul 2014 21:23:50 -0400 (EDT) Date: Thu, 24 Jul 2014 21:23:50 -0400 (EDT) From: Benjamin Kaduk To: abfab@ietf.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixCmqrLti48Vgg9sX9Sw+Xn/D6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKO7jzIWfGOpaN/o1MD4mrmLkZNDQsBEYuumZSwQtpjEhXvr 2boYuTiEBGYzSbyf1cYK4RxjlJh64y4jhHOdSWLj8ZvsEE4Do8TLxY/ZQPpZBLQlDn8/yQRi swmoSMx8sxEozsEhIiAkceZLCkhYWMBFYu6sHkYQm1fAUWLKnLdgZ4gK6Eis3j+FBSIuKHFy 5hMwm1nAUuLf2l+sExj5ZiFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0Qv NaV0EyMomNhdVHYwNh9SOsQowMGoxMPbUX8xWIg1say4MvcQoyQHk5Ior+gKoBBfUn5KZUZi cUZ8UWlOavEhRgkOZiURXre5QDnelMTKqtSifJiUNAeLkjjvW2urYCGB9MSS1OzU1ILUIpis DAeHkgRv0QagRsGi1PTUirTMnBKENBMHJ8hwHqDhYDW8xQWJucWZ6RD5U4y6HIv2v+xmEmLJ y89LlRLnDQApEgApyijNg5sDSwKvGMWB3hLmzQKp4gEmELhJr4CWMAEteZVwHmRJSSJCSqqB sf1thuSf2gTVeP9rnPtaH6+Ubftc47fN07dje8gK5SSLupfNjk1nrauLVD+uvmLlpPmjtao3 sXitvqLrrpxXM89tfMvYJR0m93iB7mzhRQqPt/z2+NZTZDwtOvevh2KoNpcy/xK2GebxGhNa HnbyLd7k3/jg9+3HsS/mzXzxN8rqQHrFjs33lViKMxINtZiLihMBtaFAit0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/VMshFpUsFQqhPqBvXQL_-bJKpOA X-Mailman-Approved-At: Mon, 04 Aug 2014 06:01:48 -0700 Subject: [abfab] comments on draft-ietf-abfab-usability-ui-considerations-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 01:23:55 -0000 Hi all, I'm just a visitor to abfab at the moment, but I ended up with this draft open in my browser after listening to today's session. It generally seems reasonable, but I had a few editorial notes: In the last paragraph of 6.3.1, there's a typo in "a secure a manner as possible" -- the first 'a' should be "as". The last sentence of that paragraph is also a little unclear, as to what the 'this' is which may be not done properly. In the second paragraph of section 7, "manipulate it and control" should have an "it" after "control" (the "it" after "manipulate" could optionally be removed). -Ben From nobody Wed Aug 6 09:22:57 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D831A00BB for ; Wed, 6 Aug 2014 09:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ihb6fP2uTnN for ; Wed, 6 Aug 2014 09:22:50 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A00E1A0108 for ; Wed, 6 Aug 2014 09:22:49 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so9282706wiv.1 for ; Wed, 06 Aug 2014 09:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getjive.com; s=mail; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Cpr8IkNhbi04rVJX+AnCGC5tmp4J8NBo2tF0Cl7IBu8=; b=ZrDTzO2e1XkLqDuCOzGC8OsOG0Krjo87r/JbsZcdDBkTb7hFqbxmWiA3ZGEzNZI31b Z36imuYCHXmQH+PCLswguYt3kRTLd8iHUcPEcYgkqsda28zOvqGjQmRipLSsuSeV3FAQ TT6/HsOEJ6RtTxkHQUc0dUi2Q36Wx59RbPqvA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Cpr8IkNhbi04rVJX+AnCGC5tmp4J8NBo2tF0Cl7IBu8=; b=ZUU4JpEurZptvMqfFeiWwct2QaLnCQAI6BdKVkFKTGjkUZ6zcH/CdnzoxAWds39m8f 1SiC8h99/4W4Ye+sTfqU9YwY7KKjEQoykQLARx7LnrNiCsxd+1/gXI8QQF2GxArStb3Y VgygBGC6xyTeivFG11S7ud9Cy6W+X0HY+Sl21MuUN/8S69OysHWJLf+8GEDKVs1o34Q1 w0J4SEeWRt7vptIqR849fGfeE9ctij7zF4VHtJuvZwk133Uo7HVbS4pQTRQUn+RnQLIU rgxxk5djKgulWCacCudNjNioJgnxztngaJsu1QrcpgChIUn6kenbJmW5xFJ8Q7QhHSd5 JY3A== X-Gm-Message-State: ALoCoQlOVH89z59KtPzo+/r+pO7a4tlTXkEX6WLRnA5fBxfSQqDrybKA0Cjue4WWP3PG5VXA5d8g MIME-Version: 1.0 X-Received: by 10.180.75.49 with SMTP id z17mr17213357wiv.80.1407342168445; Wed, 06 Aug 2014 09:22:48 -0700 (PDT) Received: by 10.194.152.37 with HTTP; Wed, 6 Aug 2014 09:22:48 -0700 (PDT) In-Reply-To: <53E24C5D.10601@getjive.com> References: <53E24C5D.10601@getjive.com> Date: Wed, 6 Aug 2014 10:22:48 -0600 Message-ID: From: Colton Shields To: abfab@ietf.org Content-Type: multipart/alternative; boundary=f46d04389533072b4404fff86212 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/Y40Zy-YLUYWrcmNo089I532tOAc Subject: [abfab] Fwd: draft-ietf-abfab-usability-ui-considerations-01 Review X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 16:22:55 -0000 --f46d04389533072b4404fff86212 Content-Type: text/plain; charset=UTF-8 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 draft-ietf-abfab-usability-ui-considerations-01 Review >From reading the draft I feel like I understand the majority of the language and what this draft is trying to accomplish. I did not find any fundamental flaws with the draft. My comments are minor text changes. Below are my comments. Section 3 Considerations - ------------------------ Could be useful to have examples of each terminology, and what they look like. Helps readers get context. In Section 5.1 last sentence of Paragraph 1 it mentions that a NAI looks like an email address. It would be nice to have examples at the beginning of the document so readers can wrap their brains around what NAI and other terminology mean specific to this document. GSS-API is used several times in the document but is never explained or defined. Add it to section 3 as bullet point of the terminology of the document, or the first time it is used, define it. Section 3 Last Paragraph - ------------------------ "Trust anchor: An authoritative source of verification of a particular ABFAB service or Identity Provider, used to allow authentication of a server using X.509 [RFC5280]. Typically a commercial CA to allow authentication via chain of trust, or a preconfigured non-commercial certificate (e.g. self-signed)." I am unaware of what 'CA' is referring to. I assume it means a 'Certificate Authority' but I am making that assumption from context. Replace 'CA' with 'Certificate Authority (CA)', or whatever CA represents. Section 4 Paragraph 1 Last Sentence - ----------------------------------- "The simplest way to achieve the desired effect would be a process that simply takes the credentials from the currently logged in user" Remove 'simply'. It is already known that this is the simplest way. Section 5.1 Last Paragraph First Sentence - ---------------------------------------- " Beyond terminology, careful thought needs to be given to the paradigm to use when presenting identity to users, as identities and services are abstract concepts that some users may not find is easily understandable." Turn into two separate sentences: "Beyond terminology, careful thought needs to be given to the paradigm to use when presenting identity to users." "Identities and services are abstract concepts that some users may not find easy to understand." Section 5.1 Last Paragraph Last Sentence - ---------------------------------------- "Implementers may wish to keep such abstract concepts, or may wish to examine attempts to map to real world paradigms, e.g. the idea of using "Identity Cards" that are held in the user's "Wallet", as used by Microsoft Cardspace." Unsure of what this sentence is trying to say. Seems like a run on. Section 5.2 Last Sentence - ------------------------- "But for simplicity just the word "service" probably usually suffice." Remove 'probably' or 'usually'. Use one or the other but not both. Section 6 Second Sentence - ------------------------- "This section first looks at what information associated with an identity will need to managed" add 'be' to the sentence above to look like the following: "This section first looks at what information associated with an identity will need to 'be' managed" Section 6.1 Paragraph 5 - ----------------------- Unsure of what EAP means. Define in line, or define in Section 3. Section 6.2 Paragraph 1 Last sentence - ------------------------------------- Mac and Linux options are listed. Maybe list a Windows option if there is one. (I personally don't like Windows, so if you don't add this I won't be mad :) ) Section 6.3.1 Last Paragraph - ----------------------------- "An Identity Selector that allows for manual addition of identity information SHOULD try to ensure that trust anchor information is gathered and checked in a secure a manner as possible - where users have to enter and confirm all trust anchor information, or be required to explicitly agree to an insecure configuration if this is not done properly." Needs to be reworded. Especially this part 'gathered and checked in a secure a manner as possible' Possible option 'gathered and checked in a secure manner' Section 7.1.1 Numbered List 1 - ----------------------------- "such as its GSS Acceptor Name." Unaware of what GSS Acceptor Name means. Define in line or in Section 3. Spelling considerations: - ------------------------ Section 6.1 Paragraph 6 Middle of the paragraph Replace 'make' with 'makes' "any implementer is free to use whatever make sense in their implementation and conforms to good HCI/UX guidelines." Great draft, looks good, keep up the good work! - --Colton -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJT4kxdAAoJEKWz5R7vDXT7V+4H/RAVgs/TRfDtWMF0jmpQMuNZ B1v3etyH6+ZUXijy3a69RsjKg10QMuACNEbLLzOj8ItxbnIv/qzoIo2BlwLzaqxG pGEs6+U/mNmUXcU6bHyV5s/6tjiSLy1IDl/Yp+enV/20rq8Z/QGo5BbXnHK+BVar zEQAJYyikWANNG7WqaaxYj/klhtpWu7tFDylJynwkjL6cILCL/UKWIwP0gazYJLj OzXaEhQ5AMTeypenFoiZKMnnmmOeTYtUOREDIqXy3iMDnHYSGb5CxQwcyWEwDjbV GZ3IbaHkjWvWAwNNvmK9ayI0k9es20SqG5wERcx0JPUDEujqBmx+EzcJ++4n18Y= =fKq/ -----END PGP SIGNATURE----- --f46d04389533072b4404fff86212 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-----BEGIN PGP SIGNED MESSAGE--= ---
Hash: SHA512

draft-ietf-abfab-usability-ui-considerations-01 Review

From reading the draft I feel like I understand the majority of the
language and what this draft is trying to accomplish. I did not find
any fundamental flaws with the draft. My comments are minor text changes.
Below are my comments.

Section 3 Considerations
- ------------------------
Could be useful to have examples of each terminology, and what they
look like. Helps readers get context. In Section 5.1 last sentence of
Paragraph 1 it mentions that a NAI looks like an email address. It
would be nice to have examples at the beginning of the document so
readers can wrap their brains around what NAI and other terminology
mean specific to this document.

GSS-API is used several times in the document but is never explained
or defined. Add it to section 3 as bullet point of the terminology of
the document, or the first time it is used, define it.


Section 3 Last Paragraph
- ------------------------
=C2=A0 =C2=A0 =C2=A0 "Trust anchor: An authoritative source of verific= ation of a
=C2=A0 =C2=A0 =C2=A0 particular ABFAB service or Identity Provider, used to= allow
=C2=A0 =C2=A0 =C2=A0 authentication of a server using X.509 [RFC5280]. =C2= =A0Typically a
=C2=A0 =C2=A0 =C2=A0 commercial CA to allow authentication via chain of tru= st, or a
=C2=A0 =C2=A0 =C2=A0 preconfigured non-commercial certificate (e.g. self-si= gned)."

I am unaware of what 'CA' is referring to. I assume it means a
'Certificate Authority' but I am making that assumption from contex= t.
Replace 'CA' with 'Certificate Authority (CA)', or whatever= CA
represents.

Section 4 Paragraph 1 Last Sentence
- -----------------------------------
"The simplest way to achieve the desired effect would be a process
that simply takes the credentials from the currently logged in user"
Remove 'simply'. It is already known that this is the simplest way.=


Section 5.1 Last Paragraph First Sentence
- ----------------------------------------

" Beyond terminology, careful thought needs to be given to the paradig= m
=C2=A0 =C2=A0to use when presenting identity to users, as identities and se= rvices
=C2=A0 =C2=A0are abstract concepts that some users may not find is easily =C2=A0 =C2=A0understandable."

Turn into two separate sentences:
"Beyond terminology, careful thought needs to be given to the paradigm=
to use when presenting identity to users."

"Identities and services are abstract concepts that some users may not=
find easy to understand."


Section 5.1 Last Paragraph Last Sentence
- ----------------------------------------
"Implementers may wish to keep such abstract
=C2=A0 =C2=A0concepts, or may wish to examine attempts to map to real world=
=C2=A0 =C2=A0paradigms, e.g. the idea of using "Identity Cards" t= hat are held in
=C2=A0 =C2=A0the user's "Wallet", as used by Microsoft Cardsp= ace."

Unsure of what this sentence is trying to say. Seems like a run on.


Section 5.2 Last Sentence
- -------------------------
"But for simplicity just the word "service" probably usually= suffice."

Remove 'probably' or 'usually'. Use one or the other but no= t both.


Section 6 Second Sentence
- -------------------------
"This section first looks at what information associated with an
identity will need to managed"

add 'be' to the sentence above to look like the following:

"This section first looks at what information associated with an
identity will need to 'be' managed"


Section 6.1 Paragraph 5
- -----------------------
Unsure of what EAP means. Define in line, or define in Section 3.


Section 6.2 Paragraph 1 Last sentence
- -------------------------------------
Mac and Linux options are listed. Maybe list a Windows option if there
is one. (I personally don't like Windows, so if you don't add this = I
won't be mad :) )


Section 6.3.1 Last Paragraph
- -----------------------------
"An Identity Selector that allows for manual addition of identity
=C2=A0 =C2=A0information SHOULD try to ensure that trust anchor information= is
=C2=A0 =C2=A0gathered and checked in a secure a manner as possible - where = users
=C2=A0 =C2=A0have to enter and confirm all trust anchor information, or be<= br> =C2=A0 =C2=A0required to explicitly agree to an insecure configuration if t= his is
=C2=A0 =C2=A0not done properly."

Needs to be reworded. Especially this part 'gathered and checked in a secure a manner as possible'

Possible option
'gathered and checked in a secure manner'



Section 7.1.1 Numbered List 1
- -----------------------------
"such as its GSS Acceptor Name."

Unaware of what GSS Acceptor Name means. Define in line or in Section 3.

Spelling considerations:
- ------------------------

Section 6.1 Paragraph 6 Middle of the paragraph

Replace 'make' with 'makes'

"any implementer is free to use whatever make sense in their
=C2=A0 =C2=A0implementation and conforms to good HCI/UX guidelines."

Great draft, looks good, keep up the good work!

- --Colton









-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJT4kxdAAoJEKWz5R7vDXT7V+4H/RAVgs/TRfDtWMF0jmpQMuNZ
B1v3etyH6+ZUXijy3a69RsjKg10QMuACNEbLLzOj8ItxbnIv/qzoIo2BlwLzaqxG
pGEs6+U/mNmUXcU6bHyV5s/6tjiSLy1IDl/Yp+enV/20rq8Z/QGo5BbXnHK+BVar
zEQAJYyikWANNG7WqaaxYj/klhtpWu7tFDylJynwkjL6cILCL/UKWIwP0gazYJLj
OzXaEhQ5AMTeypenFoiZKMnnmmOeTYtUOREDIqXy3iMDnHYSGb5CxQwcyWEwDjbV
GZ3IbaHkjWvWAwNNvmK9ayI0k9es20SqG5wERcx0JPUDEujqBmx+EzcJ++4n18Y=3D
=3DfKq/
-----END PGP SIGNATURE-----

--f46d04389533072b4404fff86212-- From nobody Wed Aug 6 19:32:32 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEAE1A0652 for ; Wed, 6 Aug 2014 19:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.506 X-Spam-Level: ** X-Spam-Status: No, score=2.506 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHyArC9j89rj for ; Wed, 6 Aug 2014 19:32:29 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BED1A0645 for ; Wed, 6 Aug 2014 19:32:28 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id s772WR4D000831 for ; Thu, 7 Aug 2014 11:32:27 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id s772WRiY022257 for ; Thu, 7 Aug 2014 11:32:27 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id EB55E16273 for ; Thu, 7 Aug 2014 11:32:26 +0900 (JST) Received: from VAIO (unknown [133.243.119.70]) by mail2.nict.go.jp (NICT Mail) with ESMTP id E6D9316129 for ; Thu, 7 Aug 2014 11:32:26 +0900 (JST) From: "Takeshi Takahashi" To: References: In-Reply-To: Date: Thu, 7 Aug 2014 11:32:27 +0900 Message-ID: <005c01cfb1e7$d446df90$7cd49eb0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+x5x9MFYlWULWVR9KnLiPROAdYZwAAK2Gg Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith2 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/I6pLW2-fZp1ewFi1OIlKy9H_2sM Subject: [abfab] on the draft-ietf-abfab-usability-ui-considerations-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 02:32:30 -0000 Hello Rhys, I was reading the draft draft-ietf-abfab-usability-ui-considerations-01. It was an interesting document that provides assorted consideration on the user interface. Here are some minor comments and questions. Comment 1: In Section "5.1 Identity", you mentioned the possible confusion of the terms for NAI. It could be also true that some webpage use the term "username" in English while the other uses the translated term in Japanese (or any other language). Comment 2: In section "6.3.2 Manually Triggered Automated Addition", you have a paragraph "One approach to accomplishing this . into the identity selector". That is convenient, but careful setup of the website is needed. A malicious person may wish to get the piece of data of the others. The malicious person could be an internal personnel who has right to access the webpage. I bit of sentence that ask careful setup would be helpful since this document is intended to be a guideline for the impelemnters. Comment 3: In section "7.3 Listing Services and Identities", the section tiltle could be "7.3 Listing Services" since current text talks about the listing services, but does not talk about listing identities, I guess. Comment 4: It could be outside the scope of this draft, but is it better for us to talk about multiple use of a single identity at the same time? I mean, there are two active sessions with a single identity. It could be that third party may be using your identity. (e.g., two simultaneous login to a signle webmail account) Some alert needs to be shown to the user? Comment 5: In the terminology, you have defined the term "identity", but you also say that the definition is a bit different from the ordinary sense and the word "identifier" may fit better. Can you tell me why you dared to define the term "identity" rather than "identifier" then? Trivial comment: It would be helpful if you could spell out acronyms and abbreviations when they appear at the first time, such as HCI. Thank you. Take From nobody Wed Aug 6 19:36:01 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE91A0659 for ; Wed, 6 Aug 2014 19:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.007 X-Spam-Level: ** X-Spam-Status: No, score=2.007 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4M2ZZjdaU7Pu for ; Wed, 6 Aug 2014 19:35:58 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A131A0652 for ; Wed, 6 Aug 2014 19:35:58 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id s772ZvTP025881 for ; Thu, 7 Aug 2014 11:35:57 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id s772ZvHl023403 for ; Thu, 7 Aug 2014 11:35:57 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 0707E16273 for ; Thu, 7 Aug 2014 11:35:57 +0900 (JST) Received: from VAIO (unknown [133.243.119.70]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 022B81618F for ; Thu, 7 Aug 2014 11:35:57 +0900 (JST) From: "Takeshi Takahashi" To: References: <005c01cfb1e7$d446df90$7cd49eb0$@nict.go.jp> In-Reply-To: <005c01cfb1e7$d446df90$7cd49eb0$@nict.go.jp> Date: Thu, 7 Aug 2014 11:35:57 +0900 Message-ID: <005d01cfb1e8$517ba360$f472ea20$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHUeFeuysDieAn2VHFuApxK0miqapu636Ng Content-Language: ja X-Virus-Scanned: clamav-milter 0.97.8 at zenith1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/CpPZr9IDRaCBFsWyLqmm-yI9-Bw Subject: Re: [abfab] on the draft-ietf-abfab-usability-ui-considerations-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 02:36:00 -0000 Here is the typo. Sorry... > I bit of sentence that ask careful setup would be helpful since this document > is intended to be a guideline for the impelemnters. A bit of sentences that ask careful setup would be helpful since this document is intended to be a guideline for the implementers. Take > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Takeshi Takahashi > Sent: Thursday, August 7, 2014 11:32 AM > To: abfab@ietf.org > Subject: [abfab] on the draft-ietf-abfab-usability-ui-considerations-01 > > Hello Rhys, > > I was reading the draft draft-ietf-abfab-usability-ui-considerations-01. > It was an interesting document that provides assorted consideration on the > user interface. > Here are some minor comments and questions. > > Comment 1: > In Section "5.1 Identity", you mentioned the possible confusion of the terms > for NAI. > It could be also true that some webpage use the term "username" in English > while the other uses the translated term in Japanese (or any other language). > > Comment 2: > In section "6.3.2 Manually Triggered Automated Addition", you have a > paragraph "One approach to accomplishing this . into the identity selector". > That is convenient, but careful setup of the website is needed. > A malicious person may wish to get the piece of data of the others. > The malicious person could be an internal personnel who has right to access > the webpage. > I bit of sentence that ask careful setup would be helpful since this document > is intended to be a guideline for the impelemnters. > > Comment 3: > In section "7.3 Listing Services and Identities", the section tiltle could > be "7.3 Listing Services" since current text talks about the listing > services, but does not talk about listing identities, I guess. > > Comment 4: > It could be outside the scope of this draft, but is it better for us to > talk about multiple use of a single identity at the same time? > I mean, there are two active sessions with a single identity. It could be > that third party may be using your identity. (e.g., two simultaneous login > to a signle webmail account) Some alert needs to be shown to the user? > > Comment 5: > In the terminology, you have defined the term "identity", but you also say > that the definition is a bit different from the ordinary sense and the word > "identifier" may fit better. > Can you tell me why you dared to define the term "identity" rather than > "identifier" then? > > Trivial comment: > It would be helpful if you could spell out acronyms and abbreviations when > they appear at the first time, such as HCI. > > Thank you. > > Take > > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Tue Aug 12 20:16:05 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C452B1A00B0 for ; Tue, 12 Aug 2014 20:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sul0oigfQLn for ; Tue, 12 Aug 2014 20:16:00 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9282B1A00C2 for ; Tue, 12 Aug 2014 20:16:00 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id uy5so7840688obc.39 for ; Tue, 12 Aug 2014 20:15:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=chTAy2LXdjGLqNuoVeUHpXRqHLwpDcGnDeH/+kpxKLY=; b=DO85Fp5l9W9F5HOWTSIRwzjCDbmEG+VUOkwliPY6Zidd2577ozFu36VG2wFAc1kQqg Wu8MCfDF01cfD93V+ViBsXzo+a4Zz7GanFN9HyBLKcGjsC6n8Cn6kTQ5GiLnBbaK6HMR rpdAfB+PFKRxFB2xmIViSHuFUTIa0bcB3yiFx6WwSa6lmXoi+B8Hgww3uCpj9K1zstHA 7+UvRd09HaahRzRQIiGWej4s08GnM6jtH+hEQH50UvBzqTIp2oDbyHp+vLcXQZS1SWdC euOq10xfGc8fDZm02dmOWa7JZxVKWJ2ZU8eryJiRULw9WwawkxCdixDUyFYvIV/64v0Y yLGg== X-Gm-Message-State: ALoCoQlNr42+uq91WdMwiFhpXxzZsFZZp2+jrzLq4QjEesBagNC1+v/U9y9JDGLngsWPHFuJUUeU X-Received: by 10.60.98.206 with SMTP id ek14mr1651789oeb.51.1407899759831; Tue, 12 Aug 2014 20:15:59 -0700 (PDT) Received: from [10.117.1.6] (173.192.81.133-static.reverse.softlayer.com. [173.192.81.133]) by mx.google.com with ESMTPSA id zv11sm784488obb.24.2014.08.12.20.15.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 20:15:59 -0700 (PDT) Message-ID: <53EAD86D.105@jive.com> Date: Tue, 12 Aug 2014 21:15:57 -0600 From: tshields User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: abfab@ietf.org, Josh.Howlett@ja.net, hartmans-ietf@mit.edu X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/gLXgwsr6cMb6PyyquS7EgIxiZeM Subject: [abfab] Review of draft-ietf-abfab-aaa-saml-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 03:16:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I don't have any major notes or concerns addressing the draft as a whole as it was concise and easy to read through. Below are notes on my questions and suggestions for improvement on some specific areas. Section 2, Paragraph 5 > This document aspires to the guidelines stipulated by... "Aspires" seems like a weird word choice, consider replacing with "adheres". Section 4, Paragraph 1 > The RADIUS SAML binding defined by this binding Section 5 uses two > attributes to convey SAML assertions and protocol messages > respectively [OASIS.saml-core-2.0-os] . This sentence does not compute and can be reworded to be more meaningful. Section 4, Paragraph 1 > The Length of both of these attributes is >=5. Greater than or equal to 5 what? Section 5.2, Paragraph 2 > Support for fragmentation over UDP is not mandatory. Is support for fragmentation over UDP RECOMMENDED or OPTIONAL? May be beneficial to be more explicit here on what this draft's opinion is. If the draft doesn't care at all, then consider removing this sentence entirely. Section 5.3.2, Paragraph 2 and Paragraph 4 > The following methods are sufficient: > > o NAS identity in trusted digitally signed request. > > o NAS identity in trusted SAML federation metadata. > The following methods are sufficient: > > o RADIUS realm in trusted digitally signed request. > > o RADIUS realm in trusted SAML federation metadata. The wording here makes it unclear whether one of these alone is sufficient or whether both are required. Rewording to say something like "Satisfying the following two conditions is sufficient:" is more clear. Section 5.3.3, Paragraph 1 > This bindings calls... Correct to "This binding calls..." Section 7, Paragraph 1 > The Relying Party, acting as a NAS, attempts to validate the > Principal's credentials against a RADIUS server acting the > Principal's Identity Provider. Correct to "...Principal's credentials against a RADIUS server acting as the Principal's Identity Provider." Section 7.3.3, Paragraph 1 > If the ForceAuthn attribute on the element > (if sent by the requester) is present and true, the Identity > Provider MUST freshly establish this identity rather than relying > on any existing session state it may have with the Principal (for > example, TLS state that may be used for session resumption). Consider breaking this sentence up more and explaining why the Identity Provider must freshly establish the identity. Section 7.3.4, Paragraph 1 > The Identity Provider MUST conclude the authentication in a manner > consistent with the RADIUS authentication result, and MAY issue a > message to the Relying Party consisent with the > authentication result and as described in [OASIS.saml-core-2.0-os] > and delivered to the Relying Party using the SAML RADIUS binding. Break this sentence up and fix the typo in "consistent". Something like, "The Identity Provider MUST conclude the authentication in a manner consistent with the RADIUS authentication result. The Identity Provider MAY issue a message to the Relying Party that is consistent with the authentication result, as described in [OASIS.saml-core-2.0-os]." (The last part of this sentence doesn't make sense to me, so reword that as necessary). Section 7.3.5, Paragraph 1 > Any subsequent use of the elements is at the > discretion of the Relying Party, subject to any restrictions on > use contained within the assertions themselves or previously > established out-of-band policy governing interactions between the > Identity Provider and the Relying Party. Reword to something like: "Any subsequent use of the elements is at the discretion of the Relying Party, subject to any restrictions contained within the assertions themselves or from any previously established out-of-band policy that governs the interaction between the Identity Provider and the Relying Party." Section 7.4.2, Paragraph 2 > ... the element MUST conform to the following: > > o It MAY be signed. Extremely minor, but I found it a little distracting/funny that the first bullet in a list of MUSTs is a MAY. My recommendation is to reword the introduction to this: "... the element is subject to the following conditions." Section 7.4.3, Bullet 3 > If a used to establish a security context for > the Principal contains a SessionNotOnOrAfter attribute, the > security context SHOULD be discarded once this time is reached, > unless the service provider reestablishes the Principal's identity > by repeating the use of this profile. Why is this a SHOULD and not a MUST? If it is a SHOULD merely to allow for the situation described above (where the service provider reestablishes the identity), then it actually should be a MUST. "The security context MUST be discarded unless the service provider reestablishes the Principal's identity" is a perfectly sound requirement. - -- Troy Shields Developer of Awesome | Jive Communications, Inc. Jive.com | tshields@jive.com -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJT6thtAAoJEPpHBvvPaXlQlToQAJatdEwvYJUFeaHp2/Es5cj8 WdKgqhBkgyBkVSHw4yezgoWJsWsduln8943zglxPnohg6N/ID/Z/IavBIakcbbju PdtdxNUWl/NmV8TUQ2FRgublzUKfOkPaD+++ajCplx+lZmnti4rimCZhBAhd52iT gzgWdjFVowCqzFNoffCJvm2sx2FHvlOsOT41mq/7NRZT6f8I4T1+Rv91ZrI83ERo Pt7471Y+UcoqliQqNEs5KFZEad0Z8TqxDFiJWGuiwNIXzISrLsZmulGo0l/x33Zc LUso8rAdDq4THRcrQCshI7qvcTyQZVap1FskuasoKvBERdk/gZmxve11JZF27u0S JiuQPOA3Jt7ymyYqUCBI7kteSr5u17n/4xuxhwfE+cNsUl0oQd+k8pH86ZUk2QUX EAcJVgbUiYyCEWVATzXBcoIjUlF/xtQ4eexfjMc7Ilco1t0PvU7HdHEjzuMweKH2 huYkYZXaVebqCNVWxaatMI4TvMaJ6sbdThI0BpPvO2z3QektRCxmDC8TRv5zz4Y7 RWBzaqe3XiYAOUP75ibcinbLI5pntUpfIb45pOmtgkoCpvoFHmUiRjedEiFq3JVW bx+u1y2FDs7byciIpGeBOGK9Qg+HCPuXy5VDYxNRgoFaYiFNNl5CF2j1TU/UkF58 Yt8Bnp9oG7dopBGZkG1e =ony5 -----END PGP SIGNATURE----- From nobody Wed Aug 13 06:45:55 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721C41A01EF for ; Wed, 13 Aug 2014 06:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttq3haoTxjHf for ; Wed, 13 Aug 2014 06:45:51 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE001A01A8 for ; Wed, 13 Aug 2014 06:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D3F6B20178; Wed, 13 Aug 2014 09:42:32 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRuOLI6nS0iX; Wed, 13 Aug 2014 09:42:32 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [172.56.37.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 13 Aug 2014 09:42:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CE3D28111F; Wed, 13 Aug 2014 09:45:47 -0400 (EDT) From: Sam Hartman To: tshields References: <53EAD86D.105@jive.com> Date: Wed, 13 Aug 2014 09:45:47 -0400 In-Reply-To: <53EAD86D.105@jive.com> (tshields@jive.com's message of "Tue, 12 Aug 2014 21:15:57 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/84MziKqMtyKQeAfce7-p8LyLnFk Cc: abfab@ietf.org, hartmans-ietf@mit.edu Subject: Re: [abfab] Review of draft-ietf-abfab-aaa-saml-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 13:45:54 -0000 >>>>> "tshields" == tshields writes: Hi. most of your comments were editorial wording comments and can be addressed in editing the document. We appreciate both the editorial comments and the more technical comments I'm responding to in this message. tshields> Section 5.3.2, Paragraph 2 and Paragraph 4 >> The following methods are sufficient: >> >> o NAS identity in trusted digitally signed request. >> >> o NAS identity in trusted SAML federation metadata. >> The following methods are sufficient: >> >> o RADIUS realm in trusted digitally signed request. >> >> o RADIUS realm in trusted SAML federation metadata. tshields> The wording here makes it unclear whether one of these tshields> alone is sufficient or whether both are tshields> required. Rewording to say something like "Satisfying the tshields> following two conditions is sufficient:" is more clear. Sticking the information either in metadata or in the SAML message is sufficient, both is not required. tshields> Section 7.4.3, Bullet 3 >> If a used to establish a security context >> for the Principal contains a SessionNotOnOrAfter attribute, the >> security context SHOULD be discarded once this time is reached, >> unless the service provider reestablishes the Principal's >> identity by repeating the use of this profile. tshields> Why is this a SHOULD and not a MUST? If it is a SHOULD tshields> merely to allow for the situation described above (where tshields> the service provider reestablishes the identity), then it tshields> actually should be a MUST. "The security context MUST be tshields> discarded unless the service provider reestablishes the tshields> Principal's identity" is a perfectly sound requirement. Well, we've found in the GSS community that the user experience of ending some sorts of sessions prematurely is sufficiently bad that everyone has gone out of their way not to do it. For example if you're in the middle of downloading a file, it's far better to finish that than to kill your session because it reached an authentication time out. We're hoping to make the text in this draft consistent with what people will do rather than an ideal that would break stuff. The Kerberos community went through a lot of pain convincing themselves to do this over the years, and so that's where we're taking this from. It's certainly something that we can discuss if we think our requirements are different. From nobody Fri Aug 22 16:16:42 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB41A6FDE; Fri, 22 Aug 2014 16:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a444WanlNFv7; Fri, 22 Aug 2014 16:16:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9C11A7017; Fri, 22 Aug 2014 16:16:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140822231607.27399.72350.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 16:16:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/4KJ2DW4RP_hkmBUniN1pDpSWoUI Cc: abfab mailing list , abfab chair , RFC Editor Subject: [abfab] Document Action: 'Application Bridging for Federated Access Beyond Web (ABFAB) Architecture' to Informational RFC (draft-ietf-abfab-arch-13.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:16:41 -0000 The IESG has approved the following document: - 'Application Bridging for Federated Access Beyond Web (ABFAB) Architecture' (draft-ietf-abfab-arch-13.txt) as Informational RFC This document is the product of the Application Bridging for Federated Access Beyond web Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ Technical Summary This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. Working Group Summary The WG process, although it took some time, hasn't been particularly contentious. Instead there has been a lot of feedback from the core spec work and this specification which has necessarily delayed the work a bit. Document Quality This is an informational document that describes abfab architecture. The abfab suite of protocols has been implemented once by the moonshot project. Afaik there are no other implementations but the night is young. The work of Jim Schaad in particular has been excellent. His thoroughness and dedication to quality has meant a lot for getting this document done. Personnel The document shepherded is Leif Johansson (WG chair). The responsible AD is Stephen Farrell. RFC Editor Note (1) I-D nits notes a couple of outdated references which is fine and easy fix, but also... (2) There're some URL references of the form [1], [2] etc that need fixing - the xml is apparently correct but the txt file is not. The authors and AD know how to fix it, so please just check at AUTH-48